in PDF Format - Embedded-Control-Europe.com

Thinking TI? 

Texas Instruments’ innovative products help customers meet real-world signal processing requirements. 

Click on the videos below to learn about some of TI’s latest products. 

STELLARIS 

Stellaris Robotic Evaluation 

Board With Micrium’s uC/OS-III 

Download the Stellaris ® ARM ® 

Cortex -M3 Microcontrollers Brochure 

Download the Stellaris White Paper 

“Get to Work in 10 Minutes” 

Learn more about Stellaris ® ARM ® 

Cortex-M3-based MCUs 

Stellaris for Wireless Connectivity Solutions 

Learn more about Stellaris Wireless 

Order a Stellaris Kit 

C2000 

Getting started with the high voltage 

motor control + PFC 

Download the Motor Control Solutions Guide 

Learn more about Digital Motor Control 

High-Performance Analog >>Your Way and the platform bar are trademarks of Texas Instruments. © 2010 TI 

MSP430 

Discover the benefits of MSP430F5xx 

Ultra-Low-Power Microcontrollers 

Download the MSP430x5xx/MSP430x6xx 

Family User Guide 

Learn more about F5xx series 

Learn more about MSP430 MCUs 

DSPS 

AM389x Sitara ARM ® MPU 

Download the DSPS White Paper 

“Maximizing the Power of ARM with DSP” 

Learn more about AM389x 

Order a sample of AM3892 

www.ti.com

Tools & Software 

Cover Photo 

HCC-Embedded 

CONTENTS 

Designing NAND Flash 

into embedded systems 4 

Agile methods and practices 

for embedded systems development 6 

Analysing and optimizing the timing 

of a deeply embedded application 10 

Windows Embedded: 

Enabling Connectivity 14 

Anti-piracy protection for 

embedded systems 15 

Microcontrollers 

Motor control in air conditioners with 

dual sensorless FOC and active PFC 18 

ARM-based Kinetis MCUs and the 

future of microcontroller technology 22 

Combining ARM CPU, FPGA and 

analog functions in a single chip 25 

Optimising LED lighting performance 

and efficiency with small MCUs 28 

Will touch sensors work properly 

even with hands in various gloves? 30 

Smart Metering 

Complete solutions for intelligent 

metering systems 33 

Smart meters give endless opportunity 

to transform energy usage 35 

Low-power wireless protocols for 

the green energy market 38 

3 December 2010

TOOLS & SOFTWARE 

Designing NAND Flash 

into embedded systems 

By Dave Hughes, HCC-Embedded 

The benefits of a good design 

incorporating the latest NAND 

flash are truly stunning when 

viewed in any historical 

perspective: very large scale, 

high performance storage in a 

solid state device at relatively 

low cost. Moore’s Law is just 

not up to the job when it 

comes to progress in NAND 

flash. The only catch is that to 

get adequate reliability the 

details of the design must be 

well understood. 

n The use of NAND flash in embedded systems 

is one of the strongest trends in the industry. 

Some forecasts estimate that 2.5 billion NAND 

devices will be sold this year, with predictions 

of substantial year-on-year growth over the 

coming years. NAND flash has many advantages 

for embedded systems; high-volume storage at 

low cost, very fast access times, and very fast 

erase times make them ideal candidates for 

thousands of applications. But this feature set 

does not come without a cost; the devices are 

relatively complex to use and require a deeper 

understanding than more conventional memory 

devices. The major players in the industry are 

very much focused on supplying their main 

customers: manufacturers of SSDs, USB drives, 

Flash cards, and Mobile phones – indeed anyone 

who buys these devices in huge quantities. 

This means that when designers of embedded 

devices are researching the field, they must 

consider what is really available to them; the 

latest and greatest is probably reserved for certain 

target customers. In any case for these 

customers they are sold on reels in quantities 

that may be unrealistic for lower volume 

embedded designs. 

NAND Flash Overview 

All NAND flash is arranged as a set of blocks 

that are further subdivided into pages. Each 

page consists of a data area that has a number 

of bytes equal to a power of 2, as well as an 

additional set of bytes – the spare area that 

may be considered as a scratch pad for system 

maintenance. As with all flash the block must 

be erased before pages can be written. Most of 

the latest NAND flash devices also have 

additional restriction that pages may only be 

programmed incrementally and these pages 

must be programmed incrementally within 

the block. The spare area has three primary 

functions in most NAND flash system designs: 

n To store bad block information 

n To store error correction codes 

n To store meta-data for management 

of the flash translation layer 

It is important to note that all the bits in a 

NAND device are subject to failure, and that 

bits of the spare area are just as likely to fail as 

bits in the data area. Therefore, any error correction 

algorithm must allow for corrupt bits 

in the stored ECC, in the meta-data, and in 

any other data that are stored in the spare area. 

NAND size parameters have been growing rapidly. 

Pages have grown from 512bytes to 8K 

and more. Chip sizes have grown from 256Mbits 

to recently-announced devices with 512Gbits 

or more. The number of dies in one package 

has now reached eight. This results in morecomplex 

chip select handling. With all this, the 

error rates, and hence the error correction requirements, 

have also been growing! This phenomenon 

of increasing error rates with in- 

December 2010 4 

creasing chip capacity is a direct result of the 

die shrinkage, to line widths much less than 

35nm, which allows the expansion of capacity. 

The table summarizes typical NAND flash 

characteristics of high-end devices and how 

they have developed. The higher ECC requirement 

– the number of bits that must be correctable 

for the chip to guarantee its write/erase 

cycle limit – results in significant design issues. 

By choosing smaller devices, the more challenging 

design aspects can be reversed. The 

main penalty for this is that the price per unit 

of storage rises. The latest high-end NAND 

flash has the lowest price per GB. 

System Architecture 

Designing firmware to handle the issues raised 

by NAND flash usually results in a system 

similar to that depicted in diagram. Above the 

physical device is a low-level driver that handles 

the direct access to the NAND and also devicespecific 

features of the NAND – in particular 

the bad block detection algorithm and the ECC 

calculation. Containing all the device-specific 

functionality in the driver allows the design of a 

flash translation layer that is target-independent. 

The primary function of the flash translation 

layer (FTL) is to provide a logical block interface 

so that the application and the file system need 

not care what is going on underneath. The 

application simply addresses a range of uniform

Typical NAND flash characteristics of high-end devices 

sectors numbered 0 to the maximum number 

of sectors minus 1. Note that this maximum 

number of sectors for any NAND flash will be 

less than the total size of the physical device because 

a number of blocks must be excluded 

from the system by the FTL to handle the manufactured 

bad blocks and bad blocks that develop 

as well as for management areas for the FTL 

system. Typically this “loss” of storage space is 

well under 2% of the available blocks. 

An additional function of the FTL is to provide 

wear-leveling. Because the longevity of the 

device is specified per block, it is important to 

ensure that the blocks over the system are 

worn evenly. There are two types of wearleveling 

– dynamic and static. Dynamic wearleveling 

means that when a block is selected 

the least-used available block is used. With 

static wear-leveling, the system looks for blocks 

Standard firmware architecture for handling 

NAND Flash 

that have been little used. For instance they 

may contain static data such as the operating 

system or fixed system parameters, which static 

wear-leveling swaps into the main pool. In 

general, dynamic wear-leveling is of limited 

usefulness. Static wear-leveling is the only 

mechanism that guarantees even usage. Good 

static wear-leveling algorithms are deceptively 

complex to implement, and they must be careful 

not to be counter-productive. 

Making a Fail-Safe system 

For embedded designs where the data stored 

on the NAND flash is valuable, it is important 

to use a fail-safe system. There are several 

things to consider. The vast majority of FTLs 

are not fail-safe. This is well proven by testing 

commercial flash cards by removing the power 

while writing. Only a very few FTLs will prove 

to be reliable. Fail-safety in our definition 

means that, if a write is started, then it is either 

completed or the original data remains in 

place. There should be no indeterminate states 

for sectors. It is also important that the sectors 

be committed in the sequence that they are 

written. Without these specifications, there are 

very few file systems that can handle all the 

possible results of an unexpected reset. Hardware 

designs must take into consideration that 

when the power drops below the specification 

for programming then the device should be 

reset and the controlling system should be notified 

or reset. Without this measure the disk 

can be corrupted very quickly and unnecessary 

bad blocks are likely to be created when operating 

out of specification. 

How to do the ECC? 

Finding an appropriate and efficient solution 

is often the trickiest part of designing with 

NAND flash. One needs to balance several 

parameters: cost per byte, size of storage, 

performance and CPU overhead. This is complicated 

by the level of support provided by 

microcontrollers for the ECC function. Such 

support varies widely and may also affect 

system load. One-bit correction is relatively 


simple to implement. Some microcontrollers 

have support for this but, when this is not 

available, a software algorithm that does cross 

parity checking can be very efficient and will 

add only a minimal overhead to the system. 

However, for a higher number of ECC bits, 

more-complex algorithms are required. Even 

when only 3-bit correction is required per 512 

bytes, it is necessary to use BCH/Reed-Solomon 

algorithms. The problem with these algorithms 

is that, for most microcontroller systems, the 

CPU overhead of a software implementation 

is prohibitive and the performance hit is 

unacceptable. An additional problem is that 

execution time of the algorithm is a rapidly 

increasing function of the number of bits to be 

corrected and there is an attendant increase in 

the number of ECC bytes to be used. 

Therefore, for NAND flash devices that require 

more than the cross parity checking algorithm, 

it is necessary to find hardware support, typically 

in the microcontroller. For the microcontroller 

manufacturers this is difficult; typically 

only those microcontrollers that are 

specifically designed for multimedia applications 

include algorithms to handle 20 or more 

correction bits. For users of other microcontrollers, 

it is necessary to choose NAND devices 

that match the microcontroller’s error correcting 

capability. If there is no ECC module 

in the device then the only option is to use devices 

that require no more than 1 bit correction. 

Typically these devices include appropriate 

ECC algorithms and therefore this design issue 

is removed. This section on ECC is a brief 

overview of the subject. It is also important to 

look at the details of any specific ECC implementation, 

and to consider how it will be realized 

in software. Additionally, some thought 

should be given to how the ECC algorithm 

will perform later in the flash device’s life, 

when faulty bits occur more frequently. 

Alternatives 

There are many alternatives to using raw 

NAND for embedded designs. These may be 

effective particularly when the design under 

consideration is being produced in relatively 

low volumes or is not as cost-sensitive as largevolume 

consumer electronics products. The 

main options include: 

n Managed NAND. This usually takes the form 

of a NAND chip with additional logic. Some 

types may include only the ECC function; 

others may also include a complete FTL. 

n Flash cards/chips. These have standard, easy 

to use interfaces. Designers should be careful 

to note the issues of fail-safety that surround 

standard consumer parts. n 

5 December 2010


Agile methods and practices 

for embedded systems development 

By Ted Rivera and Renate Stueka, IBM Rational Software 

The word process is often 

seen as anathema in technical 

circles, at times with good 

reason. Agile software 

methods and practices form 

the basis of a process which, 

when coupled with modelling 

and other techniques, can 

more effectively deliver 

embedded systems. 

n Technologists tend to fall into one of two 

categories when thinking of what Agile software 

engineering may mean for embedded systems 

development. They believe: Agile can solve all 

of our problems, or, only an idiot would use 

Agile in embedded systems development. Both 

of these categories actually share a common 

trait: each evidences a lack of understanding 

of what Agile means. But similarly, there is at 

times a good deal of confusion about what an 

embedded system really is. The resulting errors 

and ambiguities lead to wrong conclusions regarding 

the possible utility of Agile on embedded 

systems projects. As such, let us return to 

the basics for a moment: what are embedded 

systems, and what do we mean by Agile? If we 

can agree on what we mean by these concepts, 

we will gain a better understanding about the 

potential value that can be realized by leveraging 

Agile for embedded systems development. 

The succinct Barr and Massa definition is a 

helpful starting point: an embedded system is a 

combination of computer hardware and software 

– and perhaps additional parts, either mechanical 

or electronic – designed to perform a 

dedicated function. We will come back to this 

idea later, but for now, let us consider this our 

working definition of an embedded system. 

Discussing what we mean by the term Agile 

may help us see clearly its possible role when 

developing software for embedded systems. 

To begin with, it is important to observe that 

Agile is not really one simple concept: firstly, 

there are methods that can be used to develop 

software in an Agile way (Scrum, XP, DSDM, 

RUP, OpenUP, etc) and secondly, there are 

Agile practices that can be used on software 

projects (e.g. continuous integration, planning 

poker, retrospectives, etc). 

Within IBM, we sometimes use a variation of 

this definition to explain to our teams what 

we mean when we talk about leveraging Agile 

on a given software development project: Agile 

is the use of continuous stakeholder feedback 

to produce high-quality consumable code 

through user stories and a series of short timeboxed 

iterations. In other words, rather than 

demanding the use of a particular method or 

practice we want our teams to stay focused on 

results, and we trust in the team’s ability to 

choose the method and practices that will 

work best on their project. We encourage the 

use of various Agile methods and practices to 

produce software in a disciplined way. 

In this light, any consideration about the use 

of Agile should be focused primarily on the 

software that is a part of the embedded system 

and how it is developed. And it is fair to say, 

that as the software in an embedded system 

grows more complex, the more likely it is that 

a disciplined implementation of an Agile soft- 


ware engineering methodology will be valuable. 

So for example, a basic thermostat may need 

comparatively trivial software to display (and 

potentially transmit) data, but by contrast, an 

intelligent air-bag system, sensitive to the 

weight and physical characteristics of a passenger, 

and governing issues associated with 

life and death, may need extensive programming. 

In these more complex situations, the 

development methodology employed can dramatically 

impact the resultant quality and efficiency 

realized – in which case, an Agile 

method, leveraging Agile practices, is increasingly 

important to consider. 

There are certainly some distinctive characteristics 

of software that is developed for embedded 

systems. Generally speaking, software must 

be developed in a custom manner in order to 

run in precisely the one embedded system it 

will be a part of. Comprehensive testing may 

be particularly difficult, given that the combination 

of computer hardware, mechanical, and 

electronic components may not be readily 

available (although modeling can temper this 

challenge). Testing may need to be more rigorous 

than for a general purpose computer – it 

is far more difficult to update software that 

may run your refrigerator than an application 

that runs on your laptop. And some embedded 

systems are life-critical: the aforementioned 

air bag, pacemakers, and X-ray machines and

other medical equipment being excellent examples. 

Still, there appears to be wiggle room 

on one key aspect of the definition of embedded 

systems we considered previously: an embedded 

system is a combination of computer 

hardware and software – and perhaps additional 

parts, either mechanical or electronic – 

designed to perform a dedicated function. An 

MP3 player is typically recognized as an embedded 

system; one would assume the dedicated 

function would be playing music. But 

what happens when my Ipod Nano suddenly 

allows me to also record videos? Is it still an 

embedded system, since there appears to be 

more than one dedicated function? Or is the 

iPod with video capability immediately a general 

purpose computer? More to the point, 

PDAs and cellphones, once conceived of as 

embedded systems, are increasingly truly better 

conceived of as general purpose computers. 

In this way, it appears increasingly likely that 

Agile methods will be increasingly valuable 

for embedded systems in the years to come, as 

they resemble general purpose computers, 

where Agile has proven to be a recognized 

force. 

In sum, the two most important points to 

make about embedded systems development 

leveraging Agile methods are these: Agile 

methodologies can be beneficial for any kind 

of software development, and embedded systems 

are increasingly complex, blurring the 

lines with general purpose computers. In addition 

to seeing the potential value of Agile 

methods, consider some basic questions that 

may help to illustrate that particular Agile 

practices may well be valuable in an embedded 

systems development environment. 

Would a team developing embedded software 

potentially benefit from pair programming or 

test-driven development? Pair programming 

is a technique where two people partner to 

write code, periodically alternating roles between 

driver and passenger. The driver writes 

the code, and the passenger helps recognize 

defects or better ways to write the code, thereby 

improving the overall quality of the code. Testdriven 

development (TDD) is a practice which 

advocates that the test is written before writing 

any code, so that when the code is written, it 

can be immediately validated. This encourages 

developers to write only the code required to 

satisfy the requirement (and nothing more). 

It seems evident that there is no inherent 

aspect of embedded software development 

that would obviate the benefits a team might 

enjoy using pair programming or TDD on a 

software project designed for general computers. 

The whole point of pair programming 

and TDD is to ensure that errors are eliminated 

as early as possible, and that the best possible 

code is written. None of this, of course, is in 


conflict with the unique characteristics of embedded 

systems. 


potentially benefit from daily scrums, i.e. daily 

stand-up meetings. Ideally, these are 15-minute 

daily meetings of the team that foster regular, 

efficient, open communication, where we ask 

one another three questions: what did you do 

yesterday? What are you working on today? 

What blocking issues are you experiencing? 

Again, there seems to be nothing unique about 

the potential applicability of this practice for 

software that is developed on embedded systems. 

What would the disadvantage be for the 

team to understand what happened yesterday, 

what will take place today, or what blocking issues 

might exist? In addition, would it not improve 

communication to arrange for those 

members of the team who are focused on the 

portions of the embedded systems that are 

not software, to also participate in daily scrums? 


benefit from developing that software through 

stable iterations? It is true that it may be difficult 

to test the software as fully as one would 

like in early iterations – but is there no benefit 

to constantly seeking to ensure the code is as 

stable as possible? 

These questions are intended to simply highlight 

the fact that while careful thought needs 

to be applied to realize the benefits of Agile 

methods and practices on embedded software 

projects, the same would be true in developing 

software for non-embedded software projects. 

Agile methods and practices have the potential 

to clearly benefit any software project. And as 

the complexity of embedded systems increases, 

and the capacity and capabilities of devices 

that run embedded software increase, the necessity 

of Agile software methods and practices 

is also likely to increase. Software development 

is a complex undertaking, and Agile methods 

and practices have been shown to allow teams 

to succeed more consistently. 

Most examinations of Agile software engineering 

will include a consideration of lean software 

development, inspired in large measure by the 

three excellent books written by Mary and 

Tom Poppendieck. The importance of lean 

concepts for embedded systems is difficult to 

overstate. The principles of lean software development 

that Mary and Tom Poppendieck 

pioneered are derived from the concepts of 

lean manufacturing. In the same way that the 

principles of lean revolutionized manufacturing, 

lean has profound implications for software 

development. And given that embedded systems 

entail both hardware and software working 

in concert, a lean approach is particularly 

appropriate. Eliminating waste and considering 

7 December 2010


the whole value stream are two of the key lean 

concepts that have potential applicability and 

relevance. A key failure point in embedded 

systems development often relates to the inability 

to overcome the pressure that software 

engineers face while waiting for hardware to 

be available and fully functional. A focus on 

lean – for example, by reducing or eliminating 

handoffs, minimizing organizational boundaries, 

focusing on the success of the whole 

product rather than components or hardware 

or software – can result in substantial improvements 

to the overall harmony of embedded 

systems projects. 

Whenever regulation or certification is involved 

for a given embedded system, there is a temptation 

to look at Agile with a certain level of 

scepticism – the Agile Manifesto states, after 

all, that we value working software over comprehensive 

documentation. Some have found 

in this phrase an excuse to stop doing all documentation, 

and where regulation or certification 

are required, such an approach would be 

ludicrous. In truth though, an Agile team 

would seek to do only the documentation that 

is necessary for a given project. If documentation 

is required for a given regulatory situation, 

then it is required and must be completed 

(ideally, producing only the documentation 

that is in fact required, and nothing more). 

But as has been considered already, Agile is 

about a lot more than documentation. As before, 

let us consider some specific Agile practices, 

and their relevance, indeed importance, 

in ensuring that the software being produced 

is of the highest possible quality. Test-driven 

development is a mechanism that can be employed 

to ensure that code quality rises. In 

fact, when done properly, this is a self-documenting 

activity: we have tests in place for 

code that is written which demonstrates its 

success. Would not doing test-driven development 

allow a team to obtain compliance more 

easily? Clearly not. Pair programming is in effect 

an approach that can be used to shorten 

the distance between defect injection and 

defect discovery. Would not doing pair programming 

allow a team to obtain compliance 

more easily? Clearly not. Refactoring is a disciplined 

technique for restructuring an existing 

body of code, altering its internal structure 

without changing its external behaviour. This 

systematic effort to restructure code heightens 

the ability of the team to understand and 

maintain that code. Would unintelligible, difficult-to-maintain 

code be more desirable for 

life-critical situations? Again, clearly not. Finally, 

consider the Agile practice known as continuous 

integration. One of the great obstacles to 

software quality relates to the late integration 

of software components – simply put, problems 

that are discovered at the eleventh hour are 

hardest to resolve. As a result, Agile emphasizes 

the need for frequent, indeed, continuous integration 

of software, so that software can be 

tested continually (ideally, with increasing 

levels of automation), and risks mitigated. 

Many other Agile practices could be considered 

similarly, and generally speaking, it is equally 

obvious that these practices are advantageous 

to quality and in no way detrimental to regulation 

or certification (automation, stand-up 

meetings, coding standards, sustainable pace, 

demos, etc). Similarly, Agile methods (i.e. 

Scrum, XP, DSDM, RUP, etc) share in common 

this key dynamic: each favours short, stable 

time-boxed iterations. The implications for 

quality are substantial: component integration 

takes place more routinely (and with shorter 

timeframes for problems to emerge), testing 

takes place on more granular elements, demonstrations 

are possible for working software, 

etc. While regulation and certification are often 

very challenging issues, it should be evident 

that Agile practices and methods can very definitely 

improve the quality of the software, 


which should enhance team posture for regulation 

or certification, rather than hinder it. 

Documentation challenges are real and must 

be addressed. But software quality issues are 

even more of a pressing matter in connection 

with regulation and certification, and Agile 

practices and methods can be leveraged to improve 

the situation tremendously. So far as 

documentation is concerned, two simple questions 

must be thoroughly considered. What 

documentation is actually required? And what 

is the most efficient way in which this documentation 

can be provided? Once the answers 

to these two questions are understood, a plan 

can be developed that will determine how 

much documentation is needed and appropriate 

for a given embedded systems project, and 

a plan for appropriate project governance can 

be determined. 

Modelling is an excellent complement to Agile 

practices and methods, contributing to the 

overall efficiency and productivity of the team. 

Modelling can help mitigate the need to wait 

for the hardware to become available before 

the software can be tested, and is increasingly 

an essential ingredient to successful embedded 

systems development. Often modelling is used 

in embedded systems development to realize 

design refinement (an iterative approach, incrementally 

increasing the level of detail) and 

for testing the system under development by 

simulating execution of the model. This allows 

early verification of system stability and completeness, 

or can help identify potential deadlocks 

in process interaction. The entire model 

can in this way be debugged without having 

the actual code running on the target, leaving 

only timing behaviour, integration and similar 

activities for target testing. IBM Rational Rhapsody, 

a model-driven environment, along with 

augmenting tools such as IBM Rational Rhapsody 

TestConductor and IBM Rational Test 

Realtime, is useful for these purposes. n 

FREE SUBSCRIPTION to ECE Magazine 

Information & Know-how for Embedded Engineers 

Technical Articles and Product News about: 

• Hardware & Software 

• Tools 

• Technologies 

www.embedded-control-europe.com/ece-magazine 

www www.embedded-conntrol-europe.com/e 

ece-magazine


Analysing and optimizing the timing 

of a deeply embedded application 

By Jens Braunes, pls 

Constantly increasing 

demands on timing behaviour 

make it extremely important 

to obtain, at an early stage, 

reliable and precise 

information about the timing 

behaviour of an application. 

The examples in this article 

show that, with the right 

tools and necessary knowhow, 

this is possible more 

simply than feared. 

n Given the constantly increasing complexity of 

embedded systems, even the smallest performance 

bug can quickly mutate to a bottleneck. 

However, there are several new processes which 

automatically recognize performance declines 

with code processing and data access, and deliver 

information how they can be eliminated, or at 

least greatly reduced, by code optimization. 

Today, in contrast to the past, the quality of 

the software is no longer solely defined by its 

stability in terms of logical errors or programming 

errors, but also by the computing power 

achieved, eventual performance declines and 

an optimum utilization of the hardware. For a 

long time now, there have been diverse profiling 

methods with the help of which performance 

bugs can be measured. However, all of these 

require code instrumentation, and therefore 

they themselves influence the timing behaviour 

of the application. This is of course unacceptable 

in deeply embedded applications that 

often have tough real-time demands. Typical 

deeply embedded automotive and industrial 

applications are characterized by the fact that 

all tasks that have to be performed are 

processed cyclically. Frequently, the length of 

the cycle is precisely determined. In addition, 

all tasks that have to be performed may not 

violate the specified time regime, even if 

exceptional situations occur. Therefore, it is 

imperative that the application must answer 

within a given response time, and may not 

violate the specification, even under high load. 

Unlike universal processors, with modern System-on-Chips 

(SoC) such as the Infineon 

TC1797 high-end microcontroller, it is not so 

much a matter of clock frequency - which is 

mostly low by comparison – as of an optimized 

complex system design, tailored to the respective 

field of application. The key for high performance 

and large data throughput lies especially 

in the low access times of the internal 

memories, specialized units and task sharing 

of the buses. Indeed, it is mostly possible to be 

able to achieve a significant performance 

increase here, assuming the right tools. 

As a rule, modern compilers generally offer 

the user a whole series of static code optimization 

possibilities - based on analysis of the 

program code - which can be applied independently 

of the target architecture. This includes, 

for example, loop unrolling, function 

inlining and common subexpression elimination, 

to name just a few. In addition, optimizing 

compilers are of course also in a position to 

take advantage of special chip features such as 

are offered, for example, by the above-mentioned 

TC1797. However, the static program 

analysis fails with this type of optimization 

approach, because the timing behaviour of 

the program under real conditions must be 

known for this. In particular, influences of the 


Figure 1. Thanks to its on-chip 

trigger logic and filter logic, the 

Multi-Core Debug Solution 

(MCDS) enables not only a 

targeted analysis of the application, 

but also of the entire 

hard and software system. 

memory subsystem on the performance can 

only be monitored and measured during the 

run-time. Following are a few of the typical 

performance bugs which can occur in this context. 

Cache effects: cached code and data are 

repeatedly replaced. Accessing the replaced data 

again is time-consuming because they must be 

fetched from the slower memory. Control flow 

with many jumps: the program is slowed down 

by jump instructions, for example if the instruction 

cache does not contain the code at 

the jump target or the processor pipelines idle. 

High interrupt load: the normal program run 

is interrupted by frequent interrupts, and again 

cache thrashing may frequently occur. 

Information about the run-time behaviour 

must first of all be gathered in order to also be 

able to consider such effects during code optimization. 

Which paths the program prefers 

through its control flow graph (CFG) is determined 

by application profiling. A CFG contains 

all possible paths through the program in the 

form of edges, which in turn connect the basic 

blocks (nodes) with one another. Basic blocks 

are linear consecutively executed sequences of 

machine instructions, which do not contain 

any branch or call. The coverage analysis - a 

process, which for example is used for profiling 

in the GNU compiler - now instruments all 

edges, which are needed for a later reconstruction 

of the control flow. The instrumentation

Figure 2. TC1797 block diagram 

inserts a code sequence in the respective edge 

and at the same time allocates a memory location 

in the target memory, which contains a 

counter. When the edge is taken, the corresponding 

counter is incremented at the same 

time. After completion of the profiling run, 

the counters are analyzed by the gcov tool and 

program parts are determined, which have a 

high share of the total run-time. In addition, 

critical paths in the program can also be determined, 

which enable a more favourable cache 

behaviour and a better utilization of the processor 

pipelines through reordering of basic blocks 

or forming of super blocks. However, as already 

mentioned at the beginning, the methods just 

described are unacceptable for deeply embedded 

applications. On the one hand, run-time 

behaviour is changed by the instrumentation 

and, on the other hand, often scarce target 

memory is occupied by the counters. Therefore, 

the approach favoured by pls eliminates the 

instrumentation and thus also its critical effects 

on the run-time behaviour and memory requirement. 

Instead of capturing the necessary 

information with help of the software, onchip 

emulators are used that non-intrusively - 


in other words, without influencing the system 

itself - permit a targeted observation of the 

same. Meanwhile, such on-chip emulators are 

available from different suppliers, for example, 

the Embedded Trace Macrocell (ETM) from 

ARM or the Multi-Core Debug Solution 

(MCDS) from Infineon. The latter will serve 

as reference platform for the following descriptions. 

Among other things, MCDS allows a cycle-accurate 

recording of the executed instructions 

(program trace), and supports a targeted analysis 

of the application and the entire hardware 

and software system respectively with a sophisticated 

on-chip trigger logic and filter 

logic. The possibility to filter data already during 

the recording is extremely important. On 

the one hand, the large amounts of data, which 

inevitably occur due to unfiltered recording, 

would very quickly bring the on-chip trace 

memory used to overflow. On the other hand, 

via the debug interface - for example JTAG - 

only a limited bandwidth is available for transfer 

of trace data to the host. Therefore, the 

user has no possibility to continuously trace. 

In addition to the trace function, the MCDS 

hardware also offers another feature - namely 

to count events, without counter values having 

to be written in the application memory - 

which is very useful for the observation of the 

timing behaviour. In our case, they are part of 

the trace output and can thus also be correlated 

with other recorded events and trace data. 

With hardware-supported coverage analysis, 

instead of instrumenting the code and locating 

counters in the target memory, the information 

about the actual control flow is determined by 

the MCDS. However, a modified version of 

the GNU compiler is required for this, which 

provides the CFG information for the gcov 

PERFECTION IN SOFTWARE PROTECTION 

CodeMeter: Embedded System Software Protection! 

Secure licensing and protection, activation based or dongle based with CodeMeter. Reduce piracy, protect IP and know-how, 

enable new business models and ensure data security and integrity. 

Order now your free SDK 

on: www.wibu.com/sdk 

MEDIA 

ACCESS 

PERFECTION IN SOFTWARE PROTECTION 

DOCUMENT 

VxWorks wear levelling 32-bit RISC Controller 

high ESD resistance 

EXT3 

fi xed BOM 

NTFS OSADL controlled fi rmware Windows CE 

Made in Germany 

Linux 

SLC-Flash 

Extended temperature range ECC FAT32 

Windows Embedded 

S.M.A.R.T Lifetime monitoring 

WIBU-SYSTEMS AG 

Rueppurrer Strasse 52-54 

D-76137 Karlsruhe 

Tel.: +49-721-93172-0 

www.wibu.com 

11 December 2010


Figure 3. The original edge (dashed line) is replaced by the instrumentation code 

analysis, but does not carry out instrumentation 

in the familiar sense. The MCDS now 

opens up the possibility to realize non-intrusive 

profiling in two different methods: either by 

program trace with subsequent coverage analy- 

Figure 4. Schematic workflow for profiling 

and code optimization 

sis, or by use of the MCDS hardware counters. 

With the program trace approach, all executed 

instructions are recorded. When a sufficiently 

long trace is present, the actual control flow is 

reconstructed via a post-trace analysis. This 

means that, at first, all CFG edges taken by the 

program are determined and afterwards the 

frequencies are calculated of how often they 

were taken. These frequencies are then made 

available to gcov in order to prepare the second, 

optimizing compiler run based on the determined 

run-time information. The question 

remains to be clarified how the limitation of 

the on-chip trace memory can be handled, because 

its capacity typically only permits a few 

milliseconds of comprehensive program trace. 

This is where the cyclical character of the observed 

application is of benefit to us. This 

allows the use of a window technique. Thereby, 

a whole series of single recordings, which were 

started at different times, are combined to a 

complete trace. A continuous program trace 

can however not be reconstructed from this, 

but nonetheless a representative assertion can 

be derived about the frequency of program 

paths taken. Incidentally, readout of the trace 

memory and reconfiguration of the trigger 

logic and filter logic can take place at runtime, 

without the system being affected in its 

timing behaviour. In contrast to the program 


trace method, with the second method, use of 

the MCDS hardware counters, the edges in 

the CFG of the program are directly observed 

by MCDS and directly associated with the 

hardware counters. The limited trace memory 

is not relevant with this method, because the 

counter values in the memory are hardly significant. 

However, a lightweight instrumentation 

is necessary for identification of the edges 

by MCDS. It can be realized by means of inserted 

NOP instructions. This instrumentation 

changes the run-time behaviour by only one 

cycle in each case and marginally affects the 

code size. The MCDS is programmed for the 

coverage analysis in such a way that address 

comparators perform the edge recognition 

and control incrementing of event counters. 

For this, the comparators are simply programmed 

to the addresses of the inserted 

NOPs. After readout of the counter values 

from the trace memory, the execution frequency 

of the edges can be directly determined. 

A disadvantage of this method is that only a 

few control flow edges per application cycle 

can be measured at the same time, due to the 

limited number of counters and address comparators. 

However, this does not represent a 

problem in practice, because here too a type 

of window technique can be used. Only a certain 

number of edges are measured in a single 

pass. After a predetermined time, the window 

is then shifted to the next group of edges and 

the measurement carried out again. The time 

duration of a measurement must however be 

sufficiently large compared to the duration of 

the application cycle - typically in the region 

of a few hundred milliseconds - in order to 

achieve acceptable statistical reliability. 

Industrial use of the process described obviously 

only makes sense if both the application 

profiling and code optimization are available 

as complete workflow. It should be emphasized, 

for practical use, the coverage analysis is not 

applied to the whole application in our example, 

but in a first step the actual run-time critical 

functions are determined. This can also 

take place with help of the MCDS. If critical 

functions are identified or also manually specified 

by the user then the other optimization 

steps such as coverage analysis and re-compilation 

are applied. Should optimization goals 

not be achieved or given constraints such as a 

limited code size not be fulfilled, it can be necessary 

to iterate several times in the workflow 

in order, for example, to change the optimization 

settings of the compiler or even the choice 

of functions to be optimized. n 

www.embedded-control-europe.com 

The Online Information Source for Europe`s Embedded Engineers 

• Product Product News 

News • 

TTechnical 

echnical Articles 

• 

C Company p y Profiles 

• 

Events

IBM Rational Software 

IBM Rational® Software helps you solve systems engineering, embedded 

software development, and system of systems challenges. Software is 

the key to innovation, providing an exponential leap in capabilities 

and flexibility. With this comes an increase in the complexity of 

product development, delivery, and management. The challenge of 

designing and building high-quality, reliable, and secure smart products 

is exploding as these devices become increasingly interconnected in a 

system of systems. IBM Rational helps companies develop and deliver 

an integrated system of systems based on smart products. 

IBM Rational solutions, part of the IBM integrated product lifecycle 

management vision, cover the three critical dimensions of smart 

products. 

Creating new value with a system of systems 

As products and systems become more inter-dependent and connected, 

companies need unique capabilities to define and deliver a system of 

systems. New business streams are opening, so the focus is more on 

managing an ever-evolving ecosystem of products and IT applications. 

Rational offers solutions for industry specific system of systems as 

well as a complete development environment of IT systems. With a 

special focus on ensuring security, these solutions help organizations 

to grow beyond delivering point products and to create new, secure, 

high-potential revenue streams. 

Systems engineering, the key to delivering 

successful smart products 

Effective systems engineering integrates mechanical, electrical, and 

software disciplines and specialty groups into a global, collaborative 

team effort. It provides a structured development process across the 

end-to-end lifecycle, considering both the business needs and technical 

functionality. IBM offers systems engineering tools, processes, and 

services that connect software engineering with product lifecycle 

management creating a nimble, open, and streamlined development 

environment. 

A business process for successful software 

engineering 

Software is a competitive differentiator. It allows you to adjust quickly 

and cost effectively to changing market demands and to offer a broad 

portfolio of products with a limited set of hardware. Rational offers a 

lifecycle software engineering solution dedicated to real-time and 

embedded software development, integrating critical capabilities 

around a common platform. 

IBM Rational DOORS, 

a family of requirements 

definition and requirements 

management solutions, 

improves quality by 

optimizing communication 

and collaboration 

and by promoting compliance. 

It can help you 

PROFILE 

reduce costs, increase efficiency and improve quality by enabling you 

to optimize requirements communication, collaboration and verification 

— throughout your organization and across your supply chain. 

IBM Rational Rhapsody is a visual development environment for 

systems engineers and software developers creating real-time or embedded 

systems and software. Rational Rhapsody helps diverse teams collaborate 

to understand 

and elaborate requirements, 

abstract complexity 

visually using 

industry standard languages 

(UML, SysML, 

AUTOSAR, DoDAF, 

MODAF, UPDM), validate 

functionality 

early in development, 

and automate delivery 

of innovative, high 

quality products. 

IBM Rational Team Concert is a complete collaborative development 

environment providing agile and traditional planning, project 

health, integrated reporting, customizable process support, work 

item management, change 

management, source code 

management and build 

management. Team Concert 

can be implemented 

in either a unified or modular 

manner. It connects 

dispersed development 

teams to increase individual 

and team productivity, 

compress development 

cycles, and rapidly deliver 

high-quality software. 

IBM Deutschland GmbH 

IBM-Allee 1 

71139 Ehningen 

Postanschrift: 71137 Ehningen 

Hallo IBM 

Tel: +49 800 225 5426 

Fax: +49 7032 15 3777 

halloibm@de.ibm.com 

www-01.ibm.com/software/rational/ 

13 December 2010


Windows Embedded: 

Enabling Connectivity 

By Mike Hall, Microsoft 

Why connectivity 

is only one 

piece to building 

a smart, 

electronically 

enabled device. 

n Following a recent presentation at London’s 

Future World Symposium, a conference focused 

on connected, smart and electronically enabled 

devices and experiences, this article will focus on 

my presentation, entitled “enabling connectivity”. 

It would be easy to focus my discussion purely 

on the topic of connectivity, but connectivity 

is really only one part of having a smart, connected, 

electronically enabled device. In future 

articles I will address other issues such as software 

trends, the user experience and cloud 

computing infrastructure; in this article I will 

focus on connectivity. 

The connectivity story would not be complete 

without a short hop into the past to look at 

where the computing and connectivity story 

started. Interestingly, there’s a recent blog post 

written by Andrew Coates called Standing on 

the shoulders of giants that compares the evolution 

of software with the changes to the 

plumbing technology from caveman times to 

modern day. This in many respects mirrors 

the transition from mainframe computing to 

smart, connected devices. 

Mainframes to Devices 

It’s hard to imagine that just 50 years ago the 

cutting edge of computing technology was the 

mainframe computer – a small number of people 

queued up with punch cards to get access to 

limited computing resources in fixed locations. 

The minicomputer was somewhat similar to 

the mainframe – it’s true that more people had 

access to computing power then, but still in 

fixed locations with limited networking capabilities. 

By the 1980s, access to computing technology 

was becoming very widespread thanks to desktop 

PCs (and thankfully no more punch cards 

or paper tape!). However, connectivity was 

still limited to the enterprise space or limited 

dial-up options. During the 1990a we really 

started to see widespread connectivity between 

people, computers and the Web. Computing 

as an experience was still tied to a physical location 

– a home or work office. 

The ability to break out of a fixed computing 

location came with the introduction of Wi-Fi 

and laptop/netbook computing. Wi-Fi is simply 

an extension of an existing LAN infrastructure, 

though, which means users are constantly 

jumping from one island of connectivity to 

another, and in many cases are locked out of 

being able to connect by needing to pay for 

access. 

The computing devices of the past were 

human-maching interaction devices. We are 

now seeing the next iteration of growth: both 

devices and connectivity are being driven by 


device-to-device (machine-to-machine or 

M2M) communication as opposed to humandevice-cloud 

communication. Demand for computational 

power and connectivity is increasingly 

driven by M2M communication. These are not 

general-purpose computing devices, but are 

fixed-function computing devices that are increasingly 

remote, mobile and movable. 

Connectivity Challenges 

Embedded device developers face a range of 

choices when figuring out which connectivity 

modules and operating system platforms to 

develop against. For M2M solution developers, 

this creates huge development and integration 

challenges if a device is to connect to the enterprise 

or cloud. Also, given the specific and 

often exacting requirements stipulated by cellular 

operators, this often results in developers 

pretty much building a custom solution for 

each geography and dealing with the integration 

issues it creates in the back end. 

When you add on top of this the sheer timeto-market 

delay involved in custom development, 

and then the often lengthier delay caused 

by the testing and certification procedures 

that cellular operators need to go through to 

ensure that they can at least anticipate the behavior 

of a device on their network, it’s not a 

surprise that a lot of OEMs and enterprise 

customers have historically given up because 

the whole process was too hard, too long and 

too expensive. The good news is that in the 

last couple of years there has been huge upsurge 

in interest in the connected devices space. Operators 

are increasingly looking to M2M as a 

major driver of new revenue streams (particularly 

with the advent of 4G). In addition, there’s 

more willingness and flexibility to develop new 

commercial structures that are needed to enable 

the development of solutions and operators. 

M2M service providers are also investing in 

services and billing layers to enhance their ability 

to manage connected devices. There’s still much 

to do to make connectivity another component 

that solution developers can add to their toolbox, 

and even more to do to realize the full potential

of connected device solutions with this basic 

foundational element in place. Let’s assume 

that we’ve solved the basic issue of getting 

connected. Our sparkling new embedded device 

now has a data pipe to the cloud and can 

communicate with other devices and cloudhosted 

Web services. There are other issues 

within the device that now need to be ad- 

dressed. Some of these relate to silicon trends 

— specifically the move from single-core to 

multicore and how our code is going to take 

advantage of available processing power. There 

are also software trends to consider when 

building smart and connected devices, such as 

the move from low-level assembler through 

C/C++ to higher-level languages. In addition, 

Anti-piracy protection for 

embedded systems 

By Oliver Winzenried, Wibu-Systems 

Anti-piracy protection 

is now available in form factors 

as small as µSD cards. 

This smaller form factors 

versions of the CodeMeter 

software and IP protection 

platform are aimed at the 

specific needs of embedded 

systems manufacturers. 

n Embedded systems play an increasingly important 

role in industries as diverse as healthcare, 

manufacturing, and retail. Products from 

pacemakers to household appliances, automobiles 

to industrial looms can contain embedded 

systems which house both microprocessors 

and custom software. Software in embedded 

systems can be the result of years of effort and 

represent a significant asset to the publisher. 

Unfortunately, along with the growth in embedded 

systems has come a growth in illegal 

piracy of software. 

Just as Blackbeard the Pirate roamed the Atlantic 

hundreds of years ago, nowadays pirates 

roam the seas of cyberspace, looking for valuable 

cargo to steal. Piracy includes stealing 

and counterfeiting entire systems to compete 

with the legal manufacturer, as well as hijacking 

process and instruction manuals and copyrighted 

and trademarked designs. Pirates skip 

the expensive research and development stage 

of product development by copying existing 

systems. A recent study by VDMA (Verband 

Deutscher Maschinen- und Anlagenbauer e.V) 

put piracy-related losses to German machine 

manufacturer companies in 2009 in excess of 

€6.4 billion, with 45 percent of companies reporting 

piracy of entire systems. Because Germany 

is one of the leading countries in the 

world for the development and sale of embedded 

systems, such piracy is of serious concern 

to both government and the private sector. To 

help find a solution to better protect embedded 

systems, Wibu-Systems teamed up with Hyperstone 

for their flash card controller and 

Swissbit for hardware assembly and testing. 

The partnership has produced the latest 

CodeMeter variants from Wibu-System: strong 

hardware-based security for software, intellectual 

property (IP), and data on CF (compact 

flash), SD (secure digital), and µSD (micro 

EMBEDDED SECURITY 

the user experience both for the device shell 

and applications should be taken into consideration, 

together with cloud-computing 

capabilities. n 

If you are interested in learning more please visit 

www.windowsembedded.com or stay tuned for 

more on connectivity later this year. 

Figure 1. CmCard/µSD, 

CmCard/SD and CmCard/CF 

providing IP protection for the 

embedded industry 

SD) cards. The developer of the popular 

CodeMeter hardware- and software-based copy 

protection systems previously only offered 

hardware solutions with USB interfaces, which 

often did not meet the needs of embedded systems 

manufacturers. The hardware protection 

systems protect software, algorithms, and data 

through strong encryption. Only the CodeMeter 

stick (CmStick) can decrypt the information 

rendering it usable. 

Aimed squarely at the tough requirements of 

embedded systems, the new CmCards provide 

equal security to their USB-based relatives 

(CmStick), with some additional features, including: 

ability to function from -25 to +85°C; 

increased resistance to electro-static discharge 

(ESD); increased resistance to corrosive gases 

and improved contact durability through a 

galvanic hard coating; fixed BOM (bill of material) 

costs for the hardware and controlled 

15 December 2010

EMBEDDED SECURITY 

Figure 2. High technology inside the CmCard/µSD Figure 3. Details of the CmCard/µSD. 

firmware, all made in Germany; complete 100 

percent compatibility with USB CodeMeter 

devices; improved read/write speed; better 

ECC (elliptic curve cryptography) error correction; 

wear leveling and bad-block handling 

via SLC flash memory and a 32-bit RISC controller; 

S.M.A.R.T. lifetime monitoring for 

flash memory; support for FAT32, NTFS, and 

EXT3 file systems. 

With CodeMeter, embedded systems manufacturers 

gain some striking benefits. These cover 

prevention of piracy and illegal copying of systems 

for counterfeiting and protection of intellectual 

property (IP) including algorithms, 

processes, and trade secrets to avoid reverse-engineering 

by competitors. Using digital signatures 

for software components, the system’s binary 

integrity can be guaranteed, reducing the 

risk of tampered software. Service manuals and 

production data including workflow descriptions 

and process diagrams can be encrypted and 

protected from falling into competitive hands. 

New business models can be enabled such as 

pay per use and pay per feature. Systems can 

be more easily ported to multiple platforms 

such as Windows Embedded, Real Time Linux 

or VxWorks because of a complete cross-platform 

protection system. The need for a new 

memory controller brought Wibu-Systems to 

Hyperstone, a leading supplier of flash memory 

controllers for SD and CF cards. This supplier 

serves a global base of customers from its 

headquarters in Konstanz, Germany, and subsidiaries 

in Taiwan and the USA. Hyperstone 

is an expert in fabless semiconductor and microprocessor 

design, and its products include 

the hyNet SoC for IP-cameras and real-time 

Ethernet as well as microcontrollers for solid 

state disks (SSD), disk-on-module (DoM), 

disk-on-board (DoB), embedded flash solutions 

such as eMMC, and flash cards such as 

CF, SD and µSD. SwissBit, headquartered in 

Bronschhofen in Switzerland, manufactures 

industrial memory products at its production 

site in Berlin, Germany. The company has a 


highly automated and top-quality production 

of COP and Die-Stack. Previously, conventional 

software protection hardware was only 

available in much larger sizes. The new 

CodeMeter hardware will have an immediate 

effect in the growing smartphone software 

market and for mobile Internet use. The company 

had to overcome some significant engineering 

challenges in designing the 

CmCard/µSD. For example, it was difficult to 

find a board manufacturing partner with technical 

expertise in miniature board fabrication. 

The overall design required a thickness of 

just 150 µm, holes of 0.1 mm, circuit paths of 

40 µm widths and different gilding on the 

plug contacts and the bondpads, all of which 

presented significant technical challenges. 

Swissbit was chosen as production partner. 

The die-stack and ultra-miniature form factor 

was a difficult challenge, in addition to the requirements 

for testing with industrial parameters, 

a fixed bill of materials, and life-cycle 

management for flash-based products. n

HCC-Embedded 

HCC-Embedded is the foremost vendor of advanced middleware for 

the embedded ecosystem. HCC’s portfolio includes file systems, flash 

translation layers, USB stacks and class drivers, TCP/IP stacks and 

protocols, and bootloaders. 

HCC’s products run in virtually any hardware environment, with or 

without an operating system. 

HCC products are used in a broad range of market segments, including 

automotive, defense/aerospace, consumer, industrial, medical, process 

control, and telecom. 

Product Overview 

File Systems – HCC offers an extensive suite of file systems, from 

which the developer can choose the most appropriate one for a particular 

application. At HCC, one size does not fit all. All HCC file 

systems are designed to be portable. They integrate easily with any 

RTOS. And, they can be used without an RTOS. 

FAT12/16/32 File Systems 

SafeFAT is a high-performance, full-featured file system. It guarantees 

that all operations will be carried out in a failsafe manner. If the 

system resets unexpectedly for any reason, it returns in a coherent, 

consistent and usable state. 

FAT is a high-performance, full-featured file system designed for embedded 

applications that require the attachment of PC-compatible 

media, such as flash card memory devices. FAT and SafeFAT are 

identical except for the failsafe feature. 

THIN is a highly optimized, reduced footprint version of our highly 

successful FAT system. THIN is designed for configurations with 

limited resources; usually it needs 1K or less of RAM. It can be used 

effectively with most 8-bit and 16-bit CPUs, as well 32-bit CPUs. 

THIN is scalable. By selecting only the functionality required for the 

application, the system is highly optimized for speed and size. 

All FAT12/16/32 products, as distributed, include pre-tested drivers 

for SD/MMC/CF cards. The API is standard and easy to use. A full 

test suite is provided in source code form to assist quick integration. 

Flash File Systems 

SafeFLASH is a high performance, 100% failsafe file system for embedded 

applications. It can be used with all NOR and NAND flash 

types as well as any media that can simulate a block-structured array. 

The file API is entirely standard, and the low-level interface is 

abstracted to the simplest possible porting layer. 

SafeFLASH performs sophisticated static and dynamic wear leveling 

and bad block management. 

TINY is a failsafe file system designed for flash devices with small 

erasable sectors. It is ideal for most standard serial flash parts, as well 

as flash-based microcontrollers with small erasable sectors (e.g., 

MSP430) and RAM drives. TINY performs dynamic wear leveling. 

Flash Translation Layers 

SafeFTL is a standard flash translation layer that allows an array of 

PROFILE 

NAND flash to be addressed as a set of standard 512Byte, 2K or 4K 

logical sectors. SafeFTL is used by HCC’s FAT12/16/32 file systems to 

access NAND memories; it then acts as the low-level driver. SafeFTL 

performs sophisticated wear leveling and bad block management. 

DFML is a clean interface layer between a file system and Atmel 

DataFlash devices. It provides a reliable and fail-safe page write operation, 

ensuring that critical data will always be reliably written to the 

device even in the event of power loss 

USB Connectivity 

HCC’s range of USB products includes a USB host stack, USB device 

stack, USB OTG stack and a comprehensive range of class drivers. 

Among the class drivers are mass storage, CDC, audio, HUB, HID 

and many others. 

HCC has ported its stacks and drivers to most of the commonly used 

microcontroller families. 

HCC specializes in providing complete tested projects, for most 

major tool-chains, to give developers instant success with the USB 

parts of their projects, and to enable them to focus on their core competences. 

Bootloaders 

HCC offers a broad range of bootloader, for a variety of circumstances 

and configurations, including the following: 

BL-FAT is a special version of HCC’s already optimized smallfootprint 

FAT file system. It is designed to be used as a simple bootloader. 

BL-EUSBD is used to configure a bootloader that loads a new code 

image from a host application over a USB connection. It uses a special 

version of HCC’s EUSBD device stack and a simple transfer protocol 

to minimize overhead. 

BL-EUSBH is a standalone bootstub that can read a new code image 

from any USB pen drive, and use it to update the target device’s 

firmware safely. The bootstub contains a special, read-only version of 

HCC’s already optimized small-footprint FAT file system, together 

with HCC’s EUSBH-MS and any EUSBH stack. 

BL-SERIAL is a bootloader for use with a serial link. 

HCC Embedded (Europe) 

Vaci ut 76 

1133 Budapest, Hungary 

+36 1 450 1302 

+36 1 450 1303 (fax) 

info@hcc embedded.com 

www.hcc-embedded.com 

HCC Embedded (Americas, Asia, Mideast) 

444 East 82nd Street 

New York, NY 10028, USA 

+1 212 734 1345 

+1 646 418 7017 (mobile) 

+1 203 738 4124 (fax) 

bernard@hcc embedded.com 

17 December 2010

MICROCONTROLLERS 

Motor control in air conditioners with 

dual sensorless FOC and active PFC 

Ronny Schulze, Infineon 

The XE164 microcontroller 

with its enhanced peripherals 

can be used to improve 

the energy efficiency of 

applications like HVAC 

(heating, ventilating and air 

conditioning) systems by 

implementing a dual 

sensorless FOC algorithm 

and active PFC. 

n Improved energy efficiency and reduced system 

costs are the driving factors in the modern 

motor control designs used in fans, pumps, 

compressors or geared motors. The implementation 

of sophisticated motor control concepts 

with sensorless field oriented control (FOC) 

and power factor correction (PFC) help to 

fulfil these demands. To demonstrate the capabilities 

of these powerful concepts, Infineon 

has built a reference design for the motor control 

of air conditioners using dual sensorless 

FOC and active PFC based on the 16-bit microcontroller 

XE164. This innovative approach 

leads to a significant improvement of the energy 

efficiency and a reduction in the bill of 

materials (BoM). 

FOC is a method to generate a three-phase 

sinusoidal signal which can easily be controlled 

in frequency and amplitude in order to minimize 

the current which means to maximize 

the efficiency. The related vector control is a 

math technique for controlling brushless DC 

and AC induction motors that reduces motor 

size, cost and power consumption. With FOC 

the efficiency of a motor can be improved significantly 

and raised up to 95%. This has a big 

impact on power consumption, motor dynamics, 

heat dissipation and noise. A sensorless 

FOC on BLDC (brushless DC motor) or 

PMSM (permanent magnet synchronous 

motor) provides additional cost benefits com- 

pared to sensor-based motor control. A BLDC 

has a permanent magnet rotor and a wound 

stator. The position of the coils (phases), with 

respect to the permanent magnet field, are 

sensed and the current switched electronically 

(commutated) to the appropriate phases. To 

sense the rotor position Hall-effect sensors are 

typically used. But the costs for an encoder or 

other position sensor can be saved, with sensorless 

approaches using the back EMF (electromagnetic 

force) of the motor to calculate 

the rotation angle and rotor position. The 

back EMF is calculated in the flux estimator, 

which is based on the voltage model of the system 

in the two-phase reference frame. A single 

shunt is enough to reconstruct the phase currents. 

System manufacturers are looking for 

cost-effective implementations of these advanced 

algorithms. This can be achieved by integrating 

both the sensorless FOC and PFC 

on a single microcontroller. With this powerful 

combination the system behavior can be exactly 

adapted and optimized to the application 

needs. 

In the following application example, a dual 

sensorless FOC with active PFC was implemented 

with the XE164 MCU. The three PWM 

units, several timers and two very fast and 

powerful ADCs make the XE164 a perfect fit 

for a variety of motor control applications. 

This application software runs on the XE164, 


Figure 1. Dual Motor 

Application Kit 

which is part of the drive card of the Dual 

Motor Drive Application Kit from Infineon. 

The EN-61000-3-2 sets the harmonic regulation 

standard on any off-line application with 

power consumption over 75W. This essentially 

demands power factor correction. Power factor 

correction is a specific filter, used in power 

supplies to increase the ratio of the real power 

and apparent power flowing to the load. 

Most motor control systems use PFC as the 

first stage of the system to reduce the harmonic 

content and reactive power, thereby improving 

the power factor and overall efficiency. The 

power factor of an AC system is defined as the 

ratio of the real power flowing to the load to 

the apparent power and is a number between 

0 and 1, frequently expressed as a percentage, 

e.g. 0.7 or 70%. Real (working) power is the 

capacity of the circuit for performing work in 

a particular time. The apparent power is the 

total available power. Due to energy stored in 

the load and returned to the source, or due to 

a non-linear load that distorts the waveform 

of the current drawn from the source, the apparent 

power can be greater than the real 

power. In an electric power system, a load 

with low power factor draws more current 

than a load with a high power factor for the 

same amount of useful power transferred. The 

higher currents increase the energy lost in the 

distribution system, and require larger wires

Figure 2. Block diagram XE164 

and other equipment. There are two different 

kinds of power factor correction: passive and 

active PFC. Linear loads with low power factor 

(such as induction motors) can be corrected 

with a passive network of capacitors or inductors. 

This filter reduces the harmonic current, 

which means that the non-linear device now 

looks like a linear load. A passive power factor 

correction is used for low loads (typically less 

then 100W) because this filter requires largevalue 

high-current inductors, which are however 

bulky and expensive and the power factor 

at the end is barely acceptable. 

Non-linear loads, such as rectifiers or SMPS, 

distort the current drawn from the system. In 

such cases, active power factor correction is 

used to counteract the distortion and raise 

power factor. An active PFC is a power electronic 

system that controls the amount of 

power drawn by a load in order to obtain a 

power factor as close as possible to unity. In 

most applications, the active PFC controls the 

input current of the load so that the current 

waveform has the same frequency, phase and 

shape as the mains voltage with no additional 

harmonics. Active power factor correctors can 

be single-stage or multi-stage. This approach 

is more complex but results in a really good 

power factor (0.99). A power converter adapts 

the used current to the sinusoidal input voltage 

taken from the power net. This active PFC circuit 

is typically a boost converter connected 

after a rectifier, using a capacitor boosted to a 

Enbedded News 

voltage level higher than the nominal rectified 

voltage (typically 350- 400V). In some applications 

passive and active PFC is combined. 

For example, motor drives with passive PFC 

can achieve power factors of about 0.7-0.75 

(more for low power applications) and with 

active PFC of 0.98 and more, while a system 

without any power factor correction has a 

power factor of only about 0.55-0.65. With active 

PFC, variations of the AC line voltage can 

be balanced and often the related devices can 

be adjusted to operate on AC power from 

about 100V (Japan) to 230V (Europe). 

The standard boost converter topology is the 

preferred method to implement PFC. A power 

factor corrected boost converter with continuous 

mode operation can decrease the total 

harmonic distortion with a simple circuit and 

easy control method. The key principle that 

drives the boost converter is the tendency of 

an inductor to resist changes in current. When 

being charged it acts as a load and absorbs energy 

(somewhat like a resistor), when being 

discharged, it acts as an energy source (somewhat 

like a battery). The voltage produced 

during the discharge phase is related to the 

rate of change of current, and not to the original 

charging voltage, thus allowing different 

input and output voltages. The basic principle 

of a boost converter consists in two distinct 

states. In the on-state of the PFC transistor, 

the inductor current will increase. In the offstate 

of the PFC transistor the only path offered 

Free E-mail Newsletter for Europe`s Embedded Engineers 

www.embedded-control-europe.com/newsletter 

www www.embedded-contro 

ol-europe.com/newwsletter 


to the inductor current is through the flyback 

diode, the capacitor C and the load R. 

This results in transferring the energy accumulated 

during the on-state into the capacitor. 

When a boost converter operates in continuous 

mode, the current through the inductor never 

falls to zero. In some cases, the amount of energy 

required by the load is low enough to be 

transferred in a time smaller than the whole 

commutation period. In this case (discontinuous 

mode) the current through the inductor 

falls to zero during part of the period. 

To show the capabilities of the design concept 

Infineon built a demonstration using an air 

conditioner (indoor and outdoor unit) and 

the Dual Motor Drive Kit based on the XE164. 

To implement the sensorless dual motor FOC 

two total independent algorithms for the compressor 

and fan of the outdoor unit were implemented: 

the CCU60 is used for the compressor 

with a PWM frequency of 15 kHz, 

while the CCU62 is used for the fan with a 

PWM frequency of 15 kHz. Both PWM frequencies 

can be increased depending on customer 

needs to above 25 kHz. The fast ADC0 

handles the precise current measurements for 

the two motors and the CAPCOM2 timers are 

used for ramp-up/down. In our design example 

the active PFC runs on the Dual Motor Drive 

Kit in a continuous conduction mode. The 

implementation consists of two parts: voltage 

boost and stabilization using a PI controller 

up to 1 kHz calculation frequency at low load, 

and the PWM modulation calculation using 

IPFC and the voltage PI controller output 

with up to 130 kHz calculation frequency. 

The CCU61 was used for PWM of the PFC 

transistor gate at a PWM frequency of 130 

kHz, while the ADC1 is used specially for PFC 

to measure the PFC current (IPFC) and DClink 

voltage (VDC). The Dual Motor Drive Kit includes 

two frequency converters which can be 

controlled either by a drive card using the 

XC878 or the XE164. The power board operates 

at 110 - 230 VAC and drives an inverter with 

900 - 1800W and a second inverter with 100 - 

200W. In addition a boost converter is integrated 

to support PFC. The power stage is capable 

of driving two motors independently. 

Coming along with optimized motor control 

software as well as a digitally isolated real time 

monitoring tool, the kit offers an easy-to-use 

reference platform for industrial drives in fans, 

19 December 2010


Air conditioner motor control: comparison of standard solution … 

…and Infineon optimized solution 

blowers, pumps, white goods or air conditioners. 

The kit contains two drive cards. One 

is based on the XC878 and can handle one 

motor and PFC, while the second drive card is 

equipped with the XE164 which can drive two 

motors and run a PFC in parallel. The complete 

software package, including documented source 

code enables simultaneous control of two 

PMSMs with sensorless FOC and digital PFC. 

In addition V/f control of induction motors 

(ACIM) is provided for quick evaluation. The 

Dual Motor Drive Application Kit comes with 

the DriveCard for the XE164F which provides 

the Timer (T13) output signal for PWM generation 

of the PFC transistor gate. The T13 

runs in edge-aligned mode with a frequency 

of 130 kHz. The compare match of the timer 

is used to trigger the ADC1 to measure the 

PFC current. In the current implementation 

with the XE164F the ADC is triggered in software. 

The period match of timer 13 is used for 

the current loop calculation and updating the 

T13 compare channel if the PFC control is activated. 

Timer 12 is used to generate the time- 


base for the voltage loop with a 1 kHz frequency. 

The PI controller calculates the error 

of the boost voltage as part of the current 

loop calculation. If only the voltage boost is 

active the pi output is directly used for PWM 

generation to stabilize the VDC. 

The XE164 is a member of the XE166 series, 

which is built around an expanded C166S V2 

core with a five-stage pipeline and exceeds the 

performance of conventional 16-bit solutions 

considerably. With an 80MHz clock speed, a 

minimum instruction execution time of 12.5ns, 

an interrupt latency of less than 100ns, a maximum 

of 768KB of on-chip flash memory, 

82KB of on-chip RAM, and several high-performance 

peripherals, these controllers are 

ideal for challenging applications in fields like 

renewable energy, drive systems, industrial automation, 

power supplies, and healthcare equipment. 

The high-performance XE164 peripherals 

include up to three PWM units (CCU6E) 

as well as two synchronized AD converters 

with up to 16 channels, 10-bit resolution, and 

a conversion time of less than 1.2µs. Tightly 

coupled with the PWM units, these high-precision 

converters can be used to control multiple 

motors. Besides generating the signal patterns 

needed to drive AC motors or inverters, 

the XE164 provides special operating modes 

for controlling brushless DC motors. 

A wide range of development tools is available 

for the XE164 family, including evaluation 

boards, debuggers, compilers, application kits 

and documentation. DAvE is a tool for initialization, 

configuration and code generation. 

All compilers for the XE164 family also include 

an OCDS debugger, and some additionally 

offer a real-time kernel and simulator. DaveDrive 

- a unique automated code generator 

for motor control algorithms - for the XE164 

is under development. In addition, Altium, in 

association with Infineon, offers a free Tasking 

C compiler with a one-year licence. 

The PFC improvements were measured with 

a power factor meter. Using the active PFC a 

power factor of 0.97 was reached, compared 

to about 0.65 without. In addition the motor 

control of the original air conditioning system 

needs two PCBs and a quite large and expensive 

inductor. The Infineon reference design uses a 

single PCB and a reduced, less expensive inductor 

due to the active PFC and control of 

two motors. Using both FOC and PFC not 

only helps the system manufacturers to achieve 

efficiencies of up to 95 percent in BLDC or 

PMSM motor applications, but also reduces 

system costs and minimizes torque ripple to 

create quieter operation. These software-based 

motor control designs are very flexible and 

also allow fast and easy customization of models 

to address multiple markets. n


ARM-based Kinetis MCUs and the 

future of microcontroller technology 

By Danny Basler, Freescale Semiconductor 

This article describes in detail 

the Kinetis MCU families, 

a scalable product portfolio 

built upon a market-leading 

process technology with 

outstanding mixed signal 

and low power capability and 

underpinned by a well-suited 

enablement system. 

n If potential is a true indication of future success, 

then new Freescale Kinetis line of ARM 

Cortex-M4-based microcontrollers (MCUs) is 

destined for the big league. Although a newcomer 

to the ARM Cortex party, this arrival is 

well-timed, and unlike some other guests there 

is no chance of another vendor turning up in 

the same outfit. Not only is Kinetis the first 

broad-market MCU portfolio to include the 

new ARM Cortex M4 core with its blend of 

MCU and DSP wizardry, low-power appeal 

and a mass of third-party partners. Kinetis 

MCUs also benefit from the new 90nm thin 

film storage (TFS) process technology. This, 

among a host of other treats, provides FlexMemory 

functionality - a unique solution for high 

endurance EEPROM and/or additional program 

and data memory. TFS represents a step 

change in the evolution of embedded memory, 

and has enabled Freescale to build one of the 

most scalable portfolios of low-power, mixedsignal 

ARM Cortex-M4-based MCUs in the industry 

while remaining within the tight price 

boundaries that define modern 32-bit design. 

With software often the critical path in timeto-market, 

Freescale is matching its IP differentiation 

with an equally impressive enablement 

suite. Kinetis MCUs come with the Eclipsebased 

CodeWarrior IDE, MQX RTOS, multiple 

connectivity and human machine interface 

(HMI) stacks and drivers (all fully RTOS inte- 

grated), and the support of the expansive ARM 

third party ecosystem. Add in the Tower system 

– a modular, open-source hardware development 

platform that speeds time-to-market and 

maximizes reuse – and the result is a one-stopshop 

for silicon, tools and run-time software 

that provides flexibility, value, and peace-ofmind 

for the embedded designer. 

Unlike conventional floating gate bit cells, TFS 

uses an array of discrete silicon nanocrystals 

(each 10-15 nanometers in diameter) for charge 

storage. This makes the bit cell less susceptible 

to leakage as a handful of nanocrystals can fail 

without the data being lost. This equates to 

improved reliability and a more robust design. 

Low power is a central theme in the Kinetis 

portfolio. With process technology a key factor 

in this, Freescale has utilized fast, low-voltage 

transistors in the read path resulting in a lower 

operating voltage range of 1.71V to 3.6V. For 

the increasing number of portable applications 

that run on dual 1.5V cells, this means system 

shutdown is no longer imminent once that 

critical 0.9V threshold has been reached (compare 

this with the 2.0V lower limit of many 

competing technologies). This operating range 

applies not only to the flash programming but 

also to the analog peripherals extending the 

usable life of the system. The excellent scalability 

and die area efficiency of TFS also allows 

for an MCU roadmap without limitation. The 


result is over 200 hardware and software compatible 

MCUs packed with broad memory 

and peripheral options, yet well within the design 

budget. Last, but by no means least, is 

FlexMemory which is configurable by the user 

as EEPROM, program memory, data memory 

or a combination of these. It is in the EEPROM 

role that FlexMemory really shows its versatility. 

Conventional EEPROM implementations offer 

write times in the 1-5ms range with erase + 

write taking approximately 5-10ms. By contrast 

FlexMemory requires as little as 100 µs (projections 

based on current design simulation) 

for word or byte writes (an order of magnitude 

less), and only 1.5 ms for erase + write operations. 

In the event of a brown-out this allows 

critical system parameters to be stored that 

would otherwise be lost. When it comes to endurance, 

figures of 1K to 100K are the industry 

norm. However, FlexMemory can support in 

excess of 10M write/erase cycles. The Flex side 

of FlexMemory comes from the configurability 

as both the quantity of EEPROM (up to 

16Kbytes), and its endurance can be adjusted 

by the user to suit the application requirements. 

Finally, unlike EEPROM emulation, FlexMemory 

does not require system resources or demand 

complex coding schemes. The performance, 

endurance and versatility of FlexMemory 

give it broad appeal as EEPROM or for storing 

large data tables, boot loaders, or additional 

program code. From November 2010, five

Figure 1. The various Kinetis MCU families 

Figure 2. Comparison of different power modes 


general purpose hardware and software compatible MCU families will 

be made available to the market, closely followed by application-specific 

devices in 2011. Freescale has engineered the Kinetis portfolio such that 

current and future performance, memory and peripheral needs can be 

accommodated all under one roof. From a compatibility perspective, 

Kinetis devices share common peripherals, memory maps and packages 

providing an easy migration path to greater/less memory and functionality 

with minimal hardware and software re-work. Phase one of the portfolio 

spans from 50MHz MCUs with 32Kbytes of flash in ultra-small footprint 

5x5mm QFN packages, up to feature-rich industrial-focused devices 

that offer 150MHz and 1Mbytes of flash memory. High RAM-to-flash 

ratios feature as standard and the excellent scalability of SG-TFS flash 

allows for easy expansion to higher memory densities in the future. The 

investment in peripherals is equally broad with analog, human-machine 

interface, control, connectivity, safety and security all provided for. 

At the heart of every Kinetis MCU is the Cortex M4 core with its DSP 

extensions, single-cycle multiply accumulate (MAC) unit and optional 

single-precision floating point unit. To further maximize bus bandwidth 

and flash execution performance, Freescale has added a direct memory 

access controller, crossbar switch, and optional on-chip cache memory 

(up to 16Kbytes). This additional processing headroom ensures that 

even demanding applications such as motor control and audio/video 

processing can be handled with relative ease while still attending to 

everyday control functions. To allow developers to take advantage of the 

DSP capabilities of the Cortex M4 core, a complimentary DSP/math library 

is offered with a range of ready-made functions. 

In terms of low power, an innovative process technology is just the tip 

of the iceberg. No less than 10 low-power run, wait and stop modes are 

available - each accompanied by multiple wake-up sources - giving the 

user an unprecedented level of granularity and control over their 

power profile. The figures are compelling with stop and run currents 

of


Figure 3. K60 family block diagram Figure 4. Freescale enablement solution 

time assurance for networked automation and 

control systems. It too comes with its own free 

software stack. Rounding things off are a multitude 

of serial interfaces including UARTs 

with support for ISO7816 SIM/smart cards 

and IrDA, an Inter-IC Sound (I2S) interface 

for audio processing hardware, and dual CAN 

modules for industrial network bridging. 

Touch-activated button, slider and rotary user 

interfaces can now be found not just in the latest 

consumer gadgets but also in home appliances, 

medical devices and industrial control 

panels. Offering aesthetic appeal, design flexibility 

and low maintenance, Freescale’s new 

Xtrinsic capacitive touch-sense technology is 

a key component of Kinetis MCUs. Functional 

in all low power modes with only minimal 

current added when enabled, it makes wakeup 

by touch accessible to a wide range of embedded 

products. Complementing the hardware 

is a touch-sense software (TSS) Library 

which includes smart auto-calibration mechanisms 

to prevent environmental issues, noise 

rejection algorithms, support for any arrangement 

of electrodes, and a GUI application for 

electrode characterization that includes demos 

and application examples. The Kinetis K30 

and K40 MCU families add segment LCD capability. 

Supporting a wide range of 3V and 

5V LCD panels of up to 320 segments, the 

LCD controller supports several blink modes 

allowing segments to be turned on and off at 

set intervals to conserve power while in stop 

mode. For display integrity, segment fault-detection 

hardware can alert the user to faults in 

the display, the display connector, and the 

board connections between the MCU and the 

display. This is particularly important in medical 

applications where an erroneous reading 

could lead to an unsafe condition for the patient. 

LCD pins can also be configured in software 

as frontplane or backplane allowing 

design changes without the need for costly 

hardware redesign. 

Kinetis MCUs continue Freescale tradition of 

offering hardware encryption via a dedicated 

co-processor. Faster and less CPU-demanding 

than software implementations, it supports a 

variety of encryption algorithms including 

DES, 3DES, AES, MD5, SHA-1 and SHA-256. 

For applications at risk from tampering, a 

hardware tamper detection module can sense 

variations in voltage, frequency, or temperature 

as well as physical attack. Should your design 

require the integration of external peripherals 

and memories, Kinetis MCUs offer a secure 

digital host controller for SD, SDIO, MMC or 

CE-ATA cards, a FlexBus for external memory 

and peripherals such as graphics displays, and 

interfaces for connecting NAND flash and 

DRAM memories. With Kinetis MCUs offering 

such high levels of performance, memory, and 

peripheral integration, locating and integrating 

all the associated software elements can challenge 

even the most experienced developer. 

Freescale offers a bundled IDE and RTOS so- 

www.embedded-control-europe.com 

The Online Information Source for Europe`s Embedded Engineers 


lution that is designed to remove this burden 

and ensure an efficient, hassle-free design cycle. 

The CodeWarrior IDE leverages the open architecture 

of the Eclipse software framework 

and includes a key (and free) feature called 

Processor Expert. This GUI-based tool essentially 

writes the code for you by encapsulating 

CPU, peripherals (internal and external) and 

software functionality into embedded components. 

The user then configures these components 

using a simple GUI and the tool generates 

the highly optimized embedded C-code. 

One of the most powerful tools of its kind in 

the market today, Processor Expert can save a 

huge amount of time in the development cycle. 

Also fully integrated with CodeWarrior is 

proven MQX RTOS. RTOS use brings communication 

stacks, graphics drivers, file systems 

and other code into one cohesive unit. By 

modularizing tasks it creates projects that are 

stable, upgradable and easily maintainable. 

Software development is an expensive business. 

The savings incurred by using the free MQX 

RTOS vs. the do-it-yourself approach can run 

into tens of thousands of dollars. Additionally, 

feature-rich MQX will not tax your system resources 

and can run in as little as 16Kbytes of 

memory. Rounding off the enablement offering 

is the open source Freescale Tower System that 

enables rapid prototyping and hardware reuse, 

and a wealth of tools from IAR Systems, Keil, 

Segger, and other ARM third-party vendors. n 

• Product News • Technical T echnical Articles • Company Com mpany p y Profiles • Events

Combining ARM CPU, FPGA and 

analog functions in a single chip 

By Rajiv Nema, Actel 

The introduction of 

SmartFusion devices gives 

the designer access to a 

single-chip solution providing 

programmable logic, plus 

programmable analog circuitry, 

alongside a powerful 

microcontroller core with 

the industry-leading 32-bit 

architecture. 

n If there were such a thing as a typical or an 

average embedded system application, the catalogues 

of the major semiconductor companies 

would be a great deal shorter. Not only can 

the designer choose from multiple processor 

architectures – most embedded system designs 

centre on a processor core – but having made 

that choice, there is an almost limitless choice 

of combinations of peripherals, communications 

ports and analog functions to accompany 

them. It speaks for the diversity of embedded 

applications that, despite having so many standard 

parts to choose from, few designers end 

up with a single-chip solution. Very often, the 

outcome of their efforts features a microcontroller 

with a number of other chips surrounding 

it. These frequently include some programmable 

logic, to provide specific logic 

functions that are not present on the microcontroller, 

and analog ICs to implement realworld 

signal interfaces. 

Choosing from limited, pre-defined feature 

sets is only one reason that designers rarely 

achieve a single-chip solution. Others include 

flexibility in the face of design changes: the 

more exact the match of features to a startingpoint 

specification, the less room there is to 

adapt to changing demands as the project progresses. 

And once your solution is implemented 

with multiple chips, the issue of design security 

looms large. With inter-chip traces exposed at 

the board level and lack of encryption on the 

MCU code and/or FPGA configuration data, 

the entire design becomes vulnerable to piracy. 

With the introduction of SmartFusion devices 

by Actel, the designer now has access to a single-chip 

solution that provides that long-awaited 

combination of programmable logic, plus 

programmable analog circuitry, alongside a 

powerful microcontroller core with the industry-leading 

32-bit architecture. Crucially, the 

comprehensive flexibility that is afforded by 

the ability to customise both analog and digital 

functions, in combination with the softwareprogrammability 

of an ARM Cortex-M3 

processor, is backed up by a tool chain of 

equal sophistication. 

The strategic investment of Actel in a nonvolatile 

flash process enables this unprecedented 

integration of three very distinct technologies. 

Some of the advantages are relatively obvious; 

a flash-programmed device has the configuration 

data for its programmable logic and program 

code for its microcontroller permanently 

stored on-chip, so it can be immediately available 

at power-up, rather than having to wait 

while the configuration is loaded from an adjacent 

EEPROM. This goes a long way to resolving 

the intellectual property (IP) security 

issue; as that configuration data is no longer 

exposed as it routes between devices, it cannot 


be intercepted or stolen. A further layer of 

protection comes from the facility to permanently 

prevent the flash memory from being 

read once it has been programmed, known as 

FlashLock on Actel devices. And with the 

ability to program devices in small batches, or 

in-system at the end of manufacturing, flashbased 

ICs suit the small-to-medium production 

volumes typical of many embedded designs. 

The same silicon process technology has other 

benefits. Flash requires high voltages (relative 

to a pure-logic CMOS process) to program 

and erase, so the capability to monitor high 

analog voltage levels is built-in. The process 

Actel employs allows for isolation between onchip 

blocks (by a triple-well structure), allowing 

analog and digital blocks to sit side-by-side 

with no interference between them. Analog 

functions, maintain excellent specifications in 

parameters such as offsets and noise, despite 

the mixed-signal context. 

In terms of their analog capability, SmartFusion 

devices have as many as three 12-bit successive-approximation 

(SAR) analog-digital converters 

(ADCs) that will run at up to 500 

Ksamples/sec (Ksps) at full resolution. Each 

ADC has a corresponding first-order, 1-bit 

sigma-delta DAC, with 500 Ksps update and 

effective 12-bit resolution. A new programmable 

element is the signal conditioning block 

25 December 2010


Figure 1. SmartFusion delivers proven FPGA 

fabric, complete ARM Cortex-M3 microcontroller 

subsystem and programmable analog, 

in a flash-based device. 

(SCB) each of which includes functions such 

as accurate high-voltage and current monitors, 

temperature monitors and high-speed (50 

nsec) comparators. The high voltage monitors, 

termed ABPS (active bipolar pre-scalers), offer 

voltage monitoring capability from -11.5V to 

+14V. Purpose-designed current monitors amplify 

the voltage drop measured across an external, 

low-ohm sense resistor; and external 

temperature monitors interpret diode-voltagedrop 

sensors. All the analog functionality is 

fully programmable, both in functional configuration 

and in parametric values, in a graphical-user-interface 

(GUI)-based software environment, 

sitting alongside the design tools 

that configure the on-board FPGA. 

SmartFusion devices have up to 500k gates of 

programmable logic identical to that used in 

the flash-based ProASIC3 FPGA device family. 

Supporting 350 MHz system performance, the 

logic is paired with up to 108Kbytes of SRAM. 

A large number of digital I/Os operate at up 

to 350 MHz, support I/O levels for interface 

standards such as LVDS, LVPECL, PCI/PCI-X 

and will drive up to 24mA. Design options include 

Actel HDL (hardware description language) 

tools chain, Libero integrated design 

environment, to create logic functions in hardware, 

or a drag-and-drop design style under 

the GUI. This route allows fast import of predefined 

IP blocks that might originate as reused 

elements from prior designs, or as functions 

from the libraries that Actel provides, or 

as IP provided by third-party suppliers. Fullyconfigurable 

logic and analog functions reside 

on the chips alongside an ARM Cortex-M3 

based microcontroller subsystem. 

Just as the logic and linear blocks offer nocompromise 

performance compared to discrete 

ICs, the ARM Cortex-M3 processor likewise is 

a fully-featured and full-specification implementation 

that is a fully-diffused functional 

block – it is a hard core, not a soft version programmed 

on to part of the FPGA logic, run- 

Figure 3. Microcontroller subsystem (MSS) based on a 100 MHz 32-bit ARM Cortex-M3 processor 


Figure 2. The programmable analog compute engine (ACE) offloads the CPU from analog tasks. 

ning with system clocks up to 100MHz, yielding 

125 DMIPS performance, with up to 512KB 

of flash memory, and 128KB of SRAM. It is 

powerful enough to run complex algorithms, 

such as precision motor control, or even multiaxial 

control of several motors. 

Alternatively, in an application such as systems 

management, it could supervise a range of 

voltage monitoring, sequencing, fan control 

and associated system housekeeping tasks, 

while still having ample capacity to also run a 

higher, user-application-level task. As a fullfeatured 

ARM Cortex-M3 design, it comes 

with a suite of peripherals including10/100 

Ethernet MAC (media access controller) and 

other interfaces include SPI, I2C, and UARTs. 

Mixed-signal I/O lines run at up to 180 MHz 

and drive up to 6mA. Other capabilities that 

the engineer who is more used to working 

with microcontrollers will recognise include

Figure 4. Complete SmartFusion diagram including FPGA fabric 

real-time clock, watchdog timers, 8-channel 

DMA controller and external memory controller 

for additional code or data storage. To 

achieve the most efficient use of silicon area, 

wwww.avionics-event.com 

ww. 

avionics-even 

t. 

co 

m 

Are 

you 

up tto 

o da date t e with the la latest test 

on: 

• Future F utur e A AAvionics 

vionics vionics • • SESAR SESAR • • EFBs EFBs • • C CCerti�cation 

C Certi�ca 

ti�ca tion 

this peripheral set is also hardwired; but the 

designer can extend and adapt it by coding any 

extra functions into the adjacent programmable 

logic. The ARM Cortex-M3 processor is closely 

Your our Invitation I Invitation 

to t o Munich – Register R Register 

Today Toda oday 

for ffor 

or Early Early Bird Bir Bi Bird 

Savings 

A multi-faceted 

event, 

with conference 

ence sessions sessions, 

ttechnology 

echnology wworkshops, 

orkshops, 

, mast 

masterclasses erclasses 

and pack packed ed exhibition �oor �oor, , AAvionics 

vionics & 

Defence 

Electronics 

Europe 

brings 

ings the the industr 

industry y ttogether 

ogether tto 

o discuss the impor 

important tant issues of the da day. y. 

It 

is the annual event 

that provides 

vides yyou 

you 

the oppor opportunity tunity 

tto 

o updat update e yyour 

our kknowledge 

nowledge 

wledge and sk 

skills ills and understand the eevolution 

v olution in the 

industr industry, y, 

tto 

o be better 

prepared 

ffor 

for or the th the futur future. e. 

Early 

Bird 

Discount - Register Register 

by 

y 16th 16th FFebruary 

February 

2011 for ffor 

or Sa Savings Savings 

Register 

yyourself 

ourself and yyour 

our colleagues as conf 

conference erence 

delegat delegates es bby 

y 16th FFebruary 

ebruar ebruary 

2011 and bene�t bene�t fr from om the Ear Early ly Bir Bird d 

Discount Rate. 

Air Airline line PPartner 

artner 

PProgramme 

rogramme 

IIf 

f yyou 

ou ar are e an industr industry y pr professional of essional wworking 

working 

ffor 

or an air airline, line, 

then yyou 

ou could bene�t bene�t bene�t fr 

from om being par part t of our Air Airline line 

PPartner 

artner 

PProgramme, 

rogramme, 

including 

VIP VIP access access tto 

to 

all areas. 

FFor or fur further ther details details, , visit 

wwww.avionics-event.com/airlinepartner. 

ww.a 

vionics- vionics-event.com/airlinepartner. 

FFor 

or full cconference 

onference 

pr programme, ogramme 

, details details of of net networking 

events, 

eexhibits 

xhibits and tto 

o rregister 

egist er online visit wwww.avionics-event.com 

ww.avionics-event.com 

OOwned 

wned 

aand 

nd 

PProduced 

roduced 

BBy: 

y: 

OOfficial fficial 

Media 

Partners: 

Premier 

r Sponsor: 

Supporting 

Organisations: 

Organisa 

a tions: 

ASICS & FPGAS 

linked to the FPGA fabric via the same, fivelayer 

AHB bus structure, with up to 16 

Gbytes/sec on-chip capacity that connects it 

with its peripheral set. Despite the immediate 

availability of this measure of processing power, 

an indication of the flexibility of the SmartFusion 

architecture can be gained from the fact 

that many front-end processing tasks do not 

need to invoke the ARM Cortex-M3 processor 

at all. Alongside the other on-chip elements is 

a totally new concept; the analog compute engine 

or ACE. This is a semi-autonomous block 

that carries out extensive analog pre- and postprocessing, 

including sampling and sequencing 

of signal acquisition, without the intervention 

of the ARM Cortex-M3 processor. 

The new series of devices provide embedded 

system designers with a true single-chip vehicle 

that is totally configurable in hardware terms, 

and fully-programmable in software, leveraging 

all the code-design resources that the ARM architecture 

can command. The chips are accompanied 

by a tool suite that will offer a familiar 

context to the software code writer, the 

analog interface designer and the RTL programmer 

alike, and that will support any of 

these specialists as they extend their skills to 

include the complete FPGA, ARM and analog 

domains. n 

Exhibition 

and 

Conference 

Confer 

e ence 

D DDate 

Date 

16-17 

March Marc 

h 2011 2 

011 

Venue V e enue 

M.O.C. M. 

O. 

C. 

Event E Even 

t Centre C e entre 

Location Locat 

t tion 

Munich, M u unich, 

Germany G Ger 

m man 

y 

SES & NEXT NEX NEXT GEN TECH TECHNOLOGY NOLOGY 

OGY 

CHALLENGES CHALLENGES AND AND SOL SOLUTIONS 

�� 

27 December 2010


Optimising LED lighting performance 

and efficiency with small MCUs 

By Steve Bowling and Jon Martis, Microchip 

LEDs are set to make 

a dramatic impact on our 

lives as a general light source, 

saving energy and offering 

compact size, portability, 

durability and long life. 

Multiple colour LEDs require 

control by a small MCU 

to tune the output, 

giving a pleasant light and 

maximising efficiency. 

n Engineers and lighting designers have recognised 

for some time that a shift to LEDs as the 

primary light source for general lighting applications 

is just around the corner. Consumers, 

too, are beginning to become aware of this 

transition, with the first LED lamps for domestic 

use beginning to appear in the retail 

chain. Expectations are high, but having been 

persuaded, and then forced by legislation, to 

abandon the incandescent lamp in favour of 

higher-efficiency products, users often had less 

than satisfactory experience with compact fluorescent 

lamps. Now the message to them is 

that LEDs will deliver long life, durability and 

efficiency, together with a pleasing spectral 

performance. 

General lighting – provision of ambient illumination 

for homes, offices and public spaces 

– is, in fact, somewhat lagging behind the pace 

of adoption of LEDs in a wide range of other 

applications. Some examples include automotive 

lighting for brake lights, running lights 

and, just starting to appear, headlights; architectural 

colour effect lighting; industrial, outdoor 

and street lighting; traffic and railway 

signals; and backlighting for LCD panels in 

televisions and monitors. In some of these applications, 

efficiency is paramount, and by far 

the most important reason for moving to 

LEDs. In others, the main reason for their 

adoption lies with the flexibility given to de- 

signers of light fittings, when they no longer 

have to provide access to replace limited-life 

bulbs. In other cases it is the degree of control 

over the light, in terms of both hue and intensity, 

that appeals to lighting engineers. 

Just as the CCFL changed the notion of a light 

source from a device that simply plugged into 

a supply, to one that required its own driver 

electronics package, so the advent of LEDs implies 

an associated page of driver and, in many 

cases, control circuitry. LEDs require constantcurrent 

drive. While a linear voltage regulator 

configured as a constant-current source may 

be acceptable for low-intensity applications, 

any design that majors on high light output 

and efficiency will demand a switch-mode 

supply. A number of common power supply 

topologies are useful for driving LEDs, including 

buck, boost, charge-pump, SEPIC, buckboost 

and flyback, each with its own advantages 

in different circuit configurations. Many vendors 

including Microchip Technology offer 

dedicated driver ICs: a microcontroller can 

add intelligence to an application when paired 

with a driver IC; or the MCU can integrate 

the LED drive function, generating the drive 

waveforms and timing. 

In the case of an application such as architectural 

effect lighting, the scope for using a 

MCU for setting precise levels to drive differ- 


ently-coloured LEDs is clear. Perhaps less obvious 

is the issue of managing the production 

of white light, where an MCU is not just 

added intelligence, but is essential. 

Single-source white LEDs are in fact blue light 

emitters, in which some of the blue light is 

used to energise a mix of phosphors that emits 

light in a range of colours from red through 

to green, to yield an overall white output. 

Many white LEDs cannot yield a high colour 

rendering index (CRI), which is a measure of 

the ability of the light source to faithfully reproduce 

all colours. Systems with a better 

quality of white light can be created by mixing 

the light from two or more LED colours. The 

light output from each colour source drifts 

with age and temperature. This can be corrected 

and the overall light output – specific 

colour or correlated colour temperature (CCT) 

– held constant by a feedback loop using a 

light sensor and a small MCU. 

A range of small, inexpensive light sensors is 

available in the market. They typically comprise 

selectable colour filters – red, green, blue or 

none (white) – and a light-level sensor. The 

light sensor can supply intensity-level data to 

the MCU in a variety of ways. Light-to-voltage 

sensors send voltage levels to an analog-todigital 

converter (ADC). Light-to-frequency 

sensors provide a variable frequency output,

where the frequency is proportional to the 

amount of light. The pulse output from these 

sensors can be accumulated in an MCU timer 

to determine the light level. Light-to-digital 

sensors typically have a serial digital interface, 

such as I²C. Each type of sensor interface has 

unique advantages and requires different MCU 

resources. 

In a complete closed loop colour-control system, 

the MCU must read the component 

colours from the light sensor, calibrate the 

light sensor output, and adjust the output of 

the individual LED drivers to achieve the desired 

colour. The choice of driver technique 

will depend on factors such as efficiency requirements, 

input voltage range, and the number 

of LEDs used. 

Different methods may be used to control the 

driver output. The MCU can generate an analog 

reference voltage using a digital-to-analog 

converter (DAC) or a digital potentiometer, 

and that voltage will directly set the LED drive 

current. Or, in an all-digital control chain, the 

MCU can provide pulse-width-modulated 

(PWM) signals that are used to modulate the 

driver output. The PWM signal can be used to 

enable/disable the driver itself, or it can be 

used to control a switch that disconnects the 

LEDs from the driver output. If PWM control 

is used, the PWM frequency is chosen to be 

high enough so that the human eye cannot detect 

any flickering. This approach can be helpful 

if the application demands maximum efficiency; 

many LEDs deliver their peak efficiency 

(light output for a given current) at, or close 

to, their rated maximum. Delivering reduced 

light levels by a pulsed drive at the peak current 

level, rather than by a reduced constant current, 

will be more efficient. 

In order to select an MCU with the proper peripherals, 

the designer must decide how much 

control resolution is required in a colour control 

system,. For a light-to-voltage sensor, the 

measurement resolution of the on-chip ADC 

will be important. A light-to-frequency sensor 

requires an MCU time base that can be incremented 

using an external clock. Light-to-digital 

sensors will require an appropriate serial communications 

interface peripheral. An MCU 

with multiple PWM peripherals is useful for 

controlling the individual LED drivers. In high 

resolution colour control systems, a PWM peripheral 

with 16 bits of control resolution or 

better is preferred. Serial communication peripherals, 

such as UARTs, SPI, I²C, LIN and 

USB, enable input/output control and display 

functionality. 

The designer will also have to determine the 

sample rate at which the control loop operates, 

and choose an MCU with appropriate compu- 

tational resources. If the system is primarily 

concerned with maintaining a constant-white 

output as the LEDs age, then a relatively infrequent 

update rate will be required. LEDs of 

different colours will typically follow different 

light output curves as they age; but they will 

also do so in response to different drive levels. 

In variable-brightness, or dimming, applications, 

the colour-control loop must update to 

keep pace with the rate of change of brightness. 

One of the most demanding applications of 

this type is in selective dimming of LCD backlighting. 

To enhance contrast in dark areas of 

a television picture, the backlighting in those 

areas is dimmed; but it must be maintained as 

a pure white in order that the LCD panel can 

continue to show the correct picture hue. In 

this case, a control loop update rate appropriate 

to the TV frame rate is required. 

A device like the PIC24FJ16GA002 is a good 

candidate for the MCU in a colour-control 

system. The PIC24 device is available in small 

28-pin packages with program memory ranging 

from 16 to 64KB and provides serial communication 

interfaces, 10-bit ADC and 5 PWM 

channels in one device. The 16-bit MCU core 

easily handles the mathematics associated with 

the sensor calibration and colour control. 

The data output from the light sensor must be 

calibrated against a reference in order to provide 

consistent results. The calibration process 

uses a chroma meter to mathematically correlate 

the output of the different colour LEDs 

and the spectral response and sensitivity of 

the light sensor to a standard colour-co-ordinate 

system, established in 1931 by the International 

Commission on Illumination (CIE), 

the CIE XYZ colour space. The calibration 

process generates a matrix of coefficients that 

must be stored in non-volatile memory with 

the luminary system, and used to determine 

the difference between the correlated and the 

desired output at each pass through the control 

system. 

Once calibrated, the MCU compares sensor 

data against desired co-ordinates on the CIE 


chromaticity plot and sets the drive values on 

each output channel until the correct CCT is 

achieved. As the control loop is operating in a 

dynamic environment, it is appropriate to use 

servo-type techniques; each channel has a PID 

(proportional-integral-derivative) algorithm 

that adjusts sensor data with the calibration 

values, evaluates the difference to target setpoint 

and adjusts the output channels accordingly. 

As with any other closed-loop PID architecture, 

the algorithm runs continuously 

to reduce the error until the output CCT 

matches the set-point CCT. PID coefficients 

can be tuned to maximise the response of the 

system, but the rate of convergence to the setpoint 

depends on the MCU efficiency in processing 

the mathematical demand. As noted 

previously, some colour control systems may 

require faster processing and response time 

than others. 

Systems that require an adjustable light source 

or one with high CRI (ability to render colours 

faithfully to the human eye) can have a wide 

range of user control requirements. A medical 

device with a graphical LCD display may have 

a tuneable LED backlight requiring the MCU 

to communicate to the LCD over SPI, as well 

as a touch-screen interface for adjusting the 

CCT and brightness. General illumination 

lighting for a commercial display case may require 

control from a central panel or computer 

to automatically adjust brightness, CCT and 

on/off based upon the time of day. Communication 

between these devices may be implemented 

using hard-wired serial bus protocols 

that are common in the lighting domain, such 

as DALI (digital addressable lighting interface, 

IEC 929) or DMX512 (a standard often seen 

in stage lighting and effects systems). Others 

may use a custom interface over USB or Ethernet. 

When retrofitting advanced lighting systems 

to existing buildings lighting, designers 

are increasingly turning away from hard-wired 

infrastructure to wireless communications and 

a protocol such as ZigBee for control. A MCU 

with flexible peripherals is an ideal host to implement 

the communication and user interfaces 

for these types of lighting applications. n 

FREE SUBSCRIPTION to ECE Magazine 

Information & Know-how for Embedded Engineers 

Technical Articles and Product News about: 

• Hardware & Software 

• Tools 

• Technologies 

www.embedded-control-europe.com/ece-magazine 

www www.embedded-control-europe.com/ece-magazine 

ol-europe.com/ece-magazine e-magazine 

29 December 2010


Will touch sensors work properly 

even with hands in various gloves? 

By Helen Francis, Atmel 

This article summarises test 

results using gloved hands to 

operate capacitive touch 

sensors. The subject must be 

dealt with on a case-by-case 

basis, but in general it is 

possible to use touch panels 

as HMI even in environments 

where gloves must be worn. 

n It can be amusing to see the liberties that 

the market allows with a hot product like the 

iPhone. For some products, reports that the 

control panel would not respond to a gloved 

hand could be considered a serious drawback. 

But for Apple, it is an opportunity to design 

special gloves and then watch as they quickly 

become part of the magic associated with the 

product. Far from being a limitation, it helps 

iPhone users to enjoy the product even more. 

Now there is a growing market for gloves designed 

to work with capacitive touch sensors. 

They are becoming high fashion items, and it 

may be that cap sense inserts will soon become 

a standard cold-weather glove feature. 

In a way this is good news for the rest of us, 

because it indicates the market has accepted 

what could be seen as a serious limitation for 

capacitive touch. It is willing to accept 

workarounds to gain the benefits of affordable 

touch controls. The problem is mainly a seasonal 

one for handhelds – it is only an issue 

during the cold weather months. But for appliance 

designers there are some applications 

where we can expect the user to want to wear 

gloves all year round. Does this mean that you 

may need to rethink your plans to put a capacitive 

touch sensor in your new product? The 

answer to that question will have a familiar 

ring to it if you have spent any time working 

with cap sense technology: it depends. It de- 

pends, that is, on the material that the glove is 

made from, the environment that it is used in 

and the design and configuration of the sensor. 

In some circumstances there is no problem at 

all, in others you may have to adapt the product 

design to accommodate, and in a few limited 

cases you would be better off looking at alternative 

technologies. 

There are a lot of variables and the most 

reliable way to discover if there is an issue 

with a particular application is to do some 

practical experiments. Some applications will 

require extensive testing and fine-tuning of a 

particular sensor design, but to get a ball-park 

feeling for the extent of the issue it is possible 

to set up some simple low- cost testing – or 

sometimes no cost at all - using manufacturers’ 

demo equipment. 

The images here show the results of a series of 

experiments carried out using the Atmel 

EVK5480E touch screen evaluation unit. Figure 

1 illustrates the response curve that you would 

expect from a bare, dry finger under normal 

conditions. It shows the sensor providing a 

clear and very definite response, which the application 

software would have no difficulty in 

identifying as a touch. Touch sensors rely for 

their operation on the availability of a good 

return path to earth via the operator’s body. 

Anything that gets in the way of this has the 


potential to reduce the sensor response. The 

extent to which a glove does that depends 

largely on the material it is made of. Household 

gloves are made of thin plastic materials which 

tend to have a high dielectric constant (the extent 

to which a substance concentrates the 

electrostatic lines of flux that a capacitive 

sensor detects), and these have very little effect 

on sensitivity. This is shown clearly in figure 2, 

which shows only a slightly reduced response. 

This is also true of the disposable vinyl gloves 

commonly used by medics, lab workers and 

mechanics - as shown in figure 3, capacitive 

touch sensors usually work as if they have 

been touched with a bare hand. 

But gloves made from knitted, woven materials 

or fleece type materials are a very different story. 

They tend to have large air cavities in the fabric. 

Air has a very low dielectric constant and the 

cavities effectively isolate the finger from the 

sensor electrode. As shown in figure 4, the 

response to a touch may be so small that it is 

difficult to distinguish from background noise. 

The response of a particular glove is also influenced 

by other factors, such as its construction, 

and environmental factors such as whether 

the glove is wet. A drastic difference in response 

can be brought about simply by dipping a 

leather work glove in clean water. Water containing 

ionic compounds such as detergents

Figure 1. Response curve from a bare, dry finger under normal 

conditions 

may produce an even more dramatic result. It 

seems clear from this that it is important to 

approach the issue of gloves and capacitive 

touch sensors on a case-by-case basis. The results 

of the testing here show the huge range 

of variability between different types of fabric. 

What they do not show is the difference that 

changes in the sensor design can make. The 

EVK5480E is supplied with one of Atmel QMatrix 

mutual capacitance type sensor arrays. It 

measures changes to a close-coupled electric 

field that is contained mainly within the panel. 

A non-directional, QTouch self capacitance 

type sensor can be set up to measure changes 

in the field directly above the panel. By changing 

the electrode and sampling capacitor size, 

the sensitivity can be changed drastically when 

Figure 3. Response curve with disposable vinyl gloves commonly used 

by medics, lab workers and mechanics 

using a QTouch device. This can even be used 

to turn the device into a proximity detector to 

allow an object to be detected some distance 

from the sensor. This approach can be used to 

get a more effective response with gloved 

hands. In an industrial application where a 

particular type of glove needs to be worn, it is 

possible to modify the size and configuration 

of the sensor to suit the specific glove. 

There are limits to the extent that this will 

work for gloves that need to provide high levels 

of thermal insulation. The large air cavities 

built in to their fabric means that, apart from 

providing gloves with special cap sense inserts, 

there is no readily available engineering solution 

to the problem. The alternative is simply to re- 


Figure 2. Slightly reduced response curve from a finger in a household 

glove 

move the glove, but there are situations where 

it may be hazardous to do that – in the extreme 

low temperatures of a cold store for instance. 

Of course there are workarounds. For instance, 

the hazard presented by the possibility of skin 

sticking to a freezing surface may be avoided by 

the use of low level local heating. A conductive 

stylus could be provided. In other cases the 

issue, as Apple quickly realised, is mainly a 

human factors problem. The solution is mainly 

going to come from good design that takes the 

user needs and capabilities into account. The 

first question that needs to be answered is 

whether the problem is serious enough to prevent 

a touch control being used in that particular 

application. That depends, of course, on many 

different factors. n 

Figure 4. The response to a touch by gloves made from knitted, woven materials 

may be so small that it is difficult to distinguish from background noise. 

31 December 2010

Complete solutions for intelligent 

metering systems 

By Ralf Hickl, Rutronik 

Today, energy efficiency 

is no longer optional but 

compulsory. Rising prices and 

the need for climate 

protection make careful use 

of energy resources more 

important than ever before. 

This includes not only the 

saving of energy but also 

more efficient distribution. 

The key is: smart meters. 

n Smart meters are digital meters for measuring 

gas, water, district heating or electricity, and 

are often equipped with a communication 

link, a non-volatile memory and a display. 

The focus is on the measured current, this 

meter is often used as a gateway for other metering 

devices. Their use is supported by legislation 

in many countries. For example in Germany, 

power supply companies have to install 

a measuring device for new installations, where 

feasible, which will display to the user the 

actual energy consumption and usage time as 

from 2010. Existing customers shall be offered 

such a measuring device. In addition, rates 

will become mandatory as from 2011 to encourage 

energy saving and time-dependent 

demand side management. An interesting market 

is opening up, considering the approximately 

40 million private households in Germany 

alone. In other countries, such as the 

UK, the use of the new measuring devices is 

also about to happen; in Italy, Sweden, Finland, 

the Netherlands, Canada and the US, the next 

meter generation has already become a reality. 

Rutronik expects a significant increase in demand 

for intelligent meters during the next 

few years. After all, the advantages speak for 

themselves – in fact, for everyone – the power 

suppliers, consumers, and the environment. A 

number of studies support this opinion. As it 

is, A.T. Kearney expects a market penetration 

in Germany of at least 50 percent by 2015. 

The market researchers of Berg Insight expect 

81.2 million smart meters to be installed 

throughout Europe by the end of 2013. For 

Rutronik, as a broadband distributor, the innovative 

meters are of particular interest, because 

almost the entire range of electronic 

components is installed in these meters. The 

customers benefit from the wide and in-depth 

portfolio. And, particularly in a market of this 

kind, where no standards have been established 

yet, their function as a manufacturer-independent 

and therefore objective advisor with technically 

experienced support staff is of value 

for the customers. 

Intelligent meters offer a multitude of possibilities 

in order to distribute energy more efficiently 

and provide a way to save it. The customer 

is provided with an overview of his actual 

consumption in real time. The display of 

the individual consumers allows him to identify 

power-hungry devices and to switch off hidden 

power consumption from equipment in standby 

mode. The consumption history allows the 

analysis and thereby the deliberate change of 

usage habits. This way, customers can increasingly 

switch on time-uncritical devices at times 

when rates are cheaper. It is even more convenient 

for the end customer, if the electric 

supply company actively switches such consumers 

on or off by remote control. Also in 

SMART METERING 

Figure 1. The MCP3901 

integrates all necessary 

features for smart meters 

view of the efficient use of energy, this is the 

optimum solution. Suppliers will be able to 

connect the devices depending on how much 

energy is currently generated and in demand. 

The key words peak shaving and valley filling 

describe the principle, that load peaks are 

shaved off, largely eliminating the need of 

power plants to cover these demand peaks. 

Demand valleys, in which generated energy is 

dissipated, will be filled. This way, power plants 

are used as efficiently as possible. Sensible distribution, 

which is controlled according to demand 

and supply, becomes more important 

the less predictable the generation of energy 

is. Due to the increasing number of regenerative 

energy sources together with the difficulty to 

store energy, available energy and demand 

must be closely matched as soon as possible. 

Smart meters have to measure current and 

voltage, store, display and transfer data and be 

able to communicate with the power supply 

companies as well as with other devices. Component 

manufacturers have responded to this 

and are offering components that meet these 

requirements. In order to measure electric energy 

electronically, the signals for current and 

voltage are received, are converted from analog 

to digital, are multiplied and integrated. Shunt 

resistors, current transformers (transmitters 

that are virtually short-circuited on the secondary 

side) and Rogowski coils are suitable 

33 December 2010


Figure 2. The STPM01 is especially suited for single-phase energy meters. 

Figure 3. Block diagram of the STPM01 

sensors for measuring the current. Unlike 

measurement using shunt resistors, the two 

inductive transducers offer the advantage of 

galvanic isolation. However, this only has an 

effect if both the power supply unit and the 

mains voltage measurement are also equipped 

with a galvanic isolation, which is associated 

with significant additional costs. 

Because of their high resolution, analog/digital 

converters of the delta/sigma type are used – 

either already in the front end or in the microcontroller. 

The MCP3901 from Microchip is 

composed of two independent delta/sigma AD 

converters with internal reference voltage 

source and upstream programmable gain amplifiers 

(PGAs). A microcontroller can read 

the conversion results via a SPI interface. The 

serial interface allows for easy galvanic isolation 

via optocouplers. Shunts and voltage dividers 

are used for measuring the mains current and 

the voltage. Depending on the required resolution, 

sampling rates of up to 64 KSPS can 

thus be achieved. 

The STPM01 from STMicroelectronics is especially 

suited for single-phase energy meters. 

In this device as well, two independent 

delta/sigma converters digitise the amplified 

current and voltage input signals. Current transformers, 

shunts and Rogowski coils can be used 

as current sensors. Alternatively, the currents 

can be measured in the forward and return 

conductors, while any fault currents are reported 


as an attempt at manipulation. A reference voltage 

has also been integrated. A digital signal 

processor on the chip calculates the energy and 

the effective values. In single operation, the 

STPM01 controls a stepper motor for a roller 

counter. In combination with a microcontroller, 

the determined values are read via a SPI interface. 

The two new ICs STPMS1 and STPMC1 allow 

for the construction of a flexible, multi-phase 

energy measurement device. 

The front end, which is called the STPMS1 or 

also smart sensor IC, is a two-channel analog 

digital converter working according to the 

sigma/delta principle with a resolution of 16 

bits. Up to five of these smart sensor ICs are 

connected to the data processing IC, the 

STPMC1, via synchronous serial interfaces. 

Each STPMS1 digitises the current and voltage 

of one phase R, S, T or N. Shunts, current 

transformers and Rogowski coils can be used 

for measuring the current. The fifth input of 

the STPMC1 has been provided for the signal 

from a Hall sensor. Using internal DSP functions, 

the device calculates the values for 

voltage, current and energy. For this purpose, 

it can be adjusted and calibrated via an internal 

OTP memory. As it is equipped with a SPI interface 

and a stepper motor output, the dataprocessing 

IC supports operation both with 

and without microcontroller. 

For the display, many rely on LCD technology. 

However, the big disadvantage is the disappearance 

of the display as soon as the electricity 

supply is interrupted. In addition, its viewing 

angle is relatively narrow. For this reason, 

Rutronik also sees potential for bistable epaper 

displays. They maintain their display 

even without any power supply, are legible 

from nearly every angle and also score through 

stronger contrast. However, meters without 

any display at all will also probably succeed. 

For households with PC and internet connection, 

it is much more convenient to call up 

their consumption data via the PC. In this 

case, a separate display on the meter would 

not be necessary. The selection of the microcontroller 

depends on the complexity of the 

front end and the communication interfaces. 

Basically, low-power microcontrollers with integrated 

drivers for liquid crystal displays are 

suitable. 

A meter that uses the MCP3901 from Microchip 

requires a relatively high processing 

power as - unlike the building blocks from 

STMicroelectronics - it does not have a builtin 

DSP unit and consequently, the values for 

current, voltage and energy from the converted 

signals still need to be calculated. It is recommended 

to use a digital signal controller from 

Microchip dsPIC family or directly a PIC32. 

In a solution using STPMxx, the microcon-

troller must only display the data that are already 

determined in the front end and handle 

the interfaces to the outside. A low-cost 8-bit 

microcontroller is sufficient for this purpose, 

for example a derivative of the new STM8L series 

with integrated LCD driver. Where demands 

on the processing power and the interfaces 

are higher, a STM32 offers good value 

for money. Very long data retention and protection 

against manipulation are ensured by a 

mask-programmed microcontroller. 

In addition to processing and displaying, an 

energy buffer or the recovery of meter readings 

in non-volatile memories is required in order 

to bridge network interruptions. In addition, 

the memory should provide protection against 

unauthorised reprogramming and manipulation. 

Long data retention in the program memory 

would be another desirable feature, as 

house and apartment owners are used to 

meters with a long life. Furthermore, an integrated 

real time clock (RTC) and a buffer for 

logged readings should be provided. The measures 

for the detection and reporting of attempts 

at manipulation and energy consumption at 

the electric meter box are summarised as antitampering. 

In the front end, this is done by 

fault current measurements. The total of the 

phase currents and the current passing through 

the neutral conductor must be zero. 

Any deviations that exceed a certain threshold 

are detected and will lead to a response. Any 

isolation faults can also be detected. For safety 

reasons, the load should be separated automatically 

from the mains in this case. Tampering 

attempts could also be detected by housing 

contacts or the measurement of incident light 

into the case, a change in the mounting position 

or the acceleration. A basic for remote management 

is a communication link between the 

power supply company and the smart meters. 

At the moment, it is not yet clear which technology 

will succeed here. Rutronik is opting 

for an internet connection to the power supply 


company, and power line communication between 

the meter and the switches of the consumers. 

For this purpose, the Rutronik partner 

STMicroelectronics already provides reference 

designs and evaluation boards. The advantages 

of the power line solution are that no additional 

wiring is required and communication also 

works through walls. A negative effect is that 

each house is different in its infrastructure and 

there may be situations where the infrastructure 

does not have adequate reliability. Wireless 

connections may be a sensible alternative. A 

star topology is suitable for the connection 

with the power supply company as not all 

households have an internet connection. This 

means, some higher-level meters are connected 

to the power supply company via the internet, 

while other meters are linked via a wireless 

connection. It goes without saying that energy 

efficiency has top priority for all components. 

At three watts, Ferraris meters have a relatively 

high intrinsic energy requirement. Intelligent 

meters need about a third of that. n 

Smart meters give endless opportunity 

to transform energy usage 

By Ian Ferguson, ARM 

Smart meters are starting to 

become a reality. There are 

concerns over system reliability, 

the systems are not yet 

well-integrated in view of the 

broad set of standards, and 

the utility companies worry 

about the cost of technical 

support and in-field updates. 

But the potential is enormous. 

n Unless you have been living on a different 

planet during the last few years, you cannot 

have missed the massive shift towards energy 

efficiency. This has been covered extensively 

in the media and is ultimately leading to a 

change in the system requirements for new 

platforms that monitor energy efficiency. Once 

designers were just concerned to ensure, for 

example, that a battery charge for a mobile device 

would last for the necessary usage period, 

now they must meet the challenge of better 

prior energy usage specifications together with 

higher performance over a broad range of 

non-mobile systems. There has been something 

of a consumer backlash during the roll-out of 

automated meter reading (AMR) systems, es- 

pecially in the US, with concerns over billing 

accuracy and questions over the real benefits 

these systems bring to end users. However, the 

combination of government-mandated programmes, 

such as the UK government’s commitment 

to equip every household with a 

smart meter by 2020, the increasing system reliability 

and usability of the technology, as 

35 December 2010


Table 1. Functionality varies depending on the type of meter. This table broadly groups 

specifications from various geographic regions. 

Figure 1. Example of connected houses 

well as the rising cost of power over time, 

means that meter deployments will increase 

over the coming years. Smart meters all comprise 

three main functions. Metrology: there 

is a subsystem to capture information measuring 

usage. In the case of a water or gas meter, 

it measures flow. In an electricity meter, it is 

an electrical circuit that measures the realtime 

current consumption. Processing: the 

usage information is converted so that the 

utility company can understand it. Communication: 

the information is transmitted back to 

the utility company and the end user. Functionality 

varies depending on the type of meter. 

Table 1 broadly groups what ARM has seen in 

terms of specifications from various geograph- 

ical regions. The systems are of course more 

complicated than this. They must incorporate 

tamper-proofing mechanisms to indicate when 

the box has been opened or the power removed. 

Additionally, the information is encrypted 

prior to transmission to the utility company 

to protect the communication channel. 

One of the main challenges in the smart metering 

market is the fragmentation of the industry 

across the world. Houses in different 

regions come in different shapes and sizes, are 

made from different materials, and also have 

the meters placed in different locations within 

the house. This is one of the reasons why electricity 

meters specify many serial ports to pro- 


vide connectivity to a diverse range of communication 

standards including ZigBee, PowerLine 

and GSM/GPRS. The price of electricity 

also varies greatly across the globe and depends 

on the time of day. Systems are required that 

can house large data tables with tariff information. 

Therefore, electricity meters need to support 

a significantly large amount of on-chip 

flash. In markets where a broad set of companies 

compete to supply electricity, this information 

can, in theory, be used to enable the meter to 

select the supplier offering the lowest price of 

electricity at a specific time. The rate at which 

silicon companies can integrate this function 

is delayed, possibly resulting in increased R&D 

costs and less reliable systems. 

Despite these challenges, it seems certain the 

teething problems that have dogged the initial 

roll-outs of smart meters will be overcome. 

The acceptance of these systems will be accelerated 

when the end users can see value. For 

the moment the main beneficiaries of AMRpowered 

meters are the utility companies. Automating 

the process of gathering usage information 

saves them cost, speeds data collection, 

and increases accuracy. 

From the point of view of the end user, when 

smart metering systems are combined with 

user interfaces such as Google PowerMeter 

and Microsoft HOHM technology, they help 

provide coarse-grain data back to the user regarding 

their utility usage. However, widespread 

adoption and acceptance requires that these 

platforms present fine-grained data of electricity 

usage to help consumers modify their 

behaviour, where possible. They should automatically 

save the end user money by switching 

to cheaper electricity tariffs depending on the 

time of day. They should take into account 

that consumers with solar panels and wind 

farms will become energy suppliers, and 

support pay-as-you-go services. 

Inside the house, a home area network (HAN), 

which could utilise DECT, Wifi, Zigbee or 

PowerLine technology, would be used to connect 

all smart devices. While in many regions 

of the world the meter might be owned by the 

utility company, the units that control the 

HAN will be the property of the home owner. 

This is really the promise of systems capable 

of advanced metering infrastructure (AMI), 

but the shift from what is effectively a oneway 

system to a two-way system will have 

huge implications for suppliers, technology 

providers and end-users alike. 

One obvious challenge is security. Firstly, it is 

imperative that the power network remains 

impervious to attack, whether it is from deliberate 

hack attempts or accidental release of 

viruses/worms by users. Additionally, given

the cost of replacing a deployed unit, the 

hardware must be capable of supporting new 

services, which means offering a reliable, seamless 

way of updating functionality remotely 

and embedding latent CPU horsepower to 

support new services. The good news is that 

E 

other industries have wrestled with and solved 

similar issues. For example, automotive gateways 

are deployed in a secure environment to 

ensure that applications can request information 

from, but cannot directly access, resources 

such as the engine management system or the 

tyres. Or, set-top boxes can be upgraded with 

new functionality overnight. Rather than reinventing 

the wheel, utility companies should 

establish relationships with firms in other industries, 

such as software providers, to address 

current smart metering challenges. It is quite 

feasible that some utility companies may even 

purchase some of these companies to try and 

kick-start their push into these areas. Often 

the technical elements of smart metering solutions 

are outside the core competency of 

utility companies. 

This shift to AMI is causing a significant upward 

trend in the functionality needed in the 

electricity meter itself. Specifications we have 

seen from various geographical regions outline 

CPU requirements for AMI-capable meters 

exceeding 60MHz with up to 0.5 Mbytes of 

flash, due to the large data tables of pricing information 

needing to be stored. These meters 

draw power from the electricity supply itself, 

so although it is desirable for the MCU to be 

energy-efficient the system specifications have 

not mandated a specific level. Gas and water 

meters are often run from batteries. CPU performance 

requirements need a system to run 

from a battery for 15-20 years, which is leading 

many OEMs to consider the use of 32-bit 

MCUs as they can accomplish the data processing 

task far more quickly than an 8- or 16bit 

MCU, thereby increasing the length of 

time the CPU can be powered down. 

Today, end users wanting to take more control 

of their power management have to be highly 

skilled in technology. If you are tech-savvy, 

you may set up a network at home which includes 

energy generated from solar panels, 

and mechanisms to control air conditioning, 

water pumps and sprinkler systems. The system 

may use a combination of predicted weather 

patterns, temperature and, electricity pricing 

information, as well as current energy 

levels/usage rates as the basis for making energy 

decisions. It is clear that many end users want 

to do the right thing and reduce their carbon 

footprint. However, the majority of end users 

need these systems to be far easier to install 

and use. This is one area where many ARM 

silicon and software ecosystem partners are 

currently focused on finding solutions. 

Many electronics manufacturers have recognised 

the opportunity to provide smart metering 

units that capture and display usage information 

most effectively. As with any emerging 

area, a range of connectivity strategies and application 

programming interfaces/protocols 

are being proposed. In the US, in addition to 

the two interfaces mentioned above, NIST 

have issued specifications. There is an alliance 

called U-SNAP (short for utility smart network 

access port) which promises to connect any 

HAN standard, present and future, to use the 

smart meters of any vendor as a gateway into 

the home. 

A coalition of appliance manufacturers called 

AHAM have indicated they are working on a 

specification. Government incentives, such as 

rebate schemes on consumer goods, which are 

used to change consumer behaviours are less 

in evidence in Europe, so the programs to 

look at SmartGrid-ready appliances seem to 

be a little behind activities in US. Up to this 

point, Europe has not seen the formation of 

these types of bodies. It is not a bad strategy 

to wait in such emerging areas to see which of 

the many proposals on offer will gain mass 

adoption, and then line up behind those which 

do, provided the infrastructure and equipment 

being developed is relatively flexible. 

So, after many years of discussion, smart meters 

are starting to become a reality. The situation 

resembles the early days of xDSL deployments. 

There are concerns over system reliability, the 

systems are not yet very well-integrated as a 

broad set of standards abound, and the utility 

companies deploying the hardware worry about 

the cost of technical support and delivering 

in-field updates to prolong the lifespan of deployed 

units. However, these units are here to 

stay and if the power industry learns from its 

predecessors, it can solve many of these challenges 

relatively quickly. 

Unlike xDSL, the increasing pressures on 

governments to reduce greenhouse gases will 

act as a driver to ensure this new network 

will be rolled out. Once the AMI infrastructure 

is in place, there will be three network 

connections into a home: a broadband connection 

(xDSL, cable, satellite, etc), a phone 

network (increasingly, this will be cellular 

as opposed to fixed line), and the power network. 

From here, only our imagination can 

hold back the types of services that will be 

deployed: energy management of course, remote 

medicine a distinct possibility, and 

even new consumer devices as electronic 

components become increasingly deployed 

in clothing, appliances and disposable goods. 

The opportunities for smart metering to 

transform the way we use energy are endless 

given the right platform. n 


The Online Information 

Source for Europe`s 

Embedded Engineers 

• Product News 

• Technical Articles 

• Company Profiles 

• Events 

• Chips & Components 

• Tools & Software 

• Boards & Modules 

www.embedded-controleurope.com 

37 December 2010


Low-power wireless protocols for 

the green energy market 

By Mark Grazier, Texas Instruments 

This article highlights 

the enormous potential for 

energy saving through 

current wireless technologies, 

and the need for interoperability 

to exploit the mass 

market. Using industrial standards 

can help to avoid reinventing 

the wheel. 

n The current economic environment has 

changed the design landscape for wireless developers 

by offering significant opportunity 

for product development in the green energy 

market. For wireless designers considering industry-standard 

protocol stacks like Zigbee, 

6LoWPAN,ISA SP100.11a and Wireless HART 

(WHART) for low-cost radio systems in their 

green designs, the new economic climate has 

raised a number of questions regarding the viability 

of industry standards. As the demand 

for green technology continues to grow, interoperability 

will become critical for wireless 

technology for mass market deployments. 

In-Stat projects that automatic meter reading 

(AMR) and smart energy will be the leading 

applications for 802.15.4 and ZigBee wireless 

sensor networks. Demand for short-range wireless 

energy monitoring and control devices 

skyrocketed in the last decade; however a large 

number of the new systems were designed 

with proprietary code and became non-starters 

in the path toward interoperability. Thanks to 

forward thinking individuals like Eric Gunther, 

Chairman and CTO of Enernex Corporation 

and the commitment of the Obama administration 

to move the USA toward energy independence, 

there is an effort to get industry 

stakeholders working together towards a common 

goal of saving energy. The Electric Power 

Research Institute (EPRI) was recently con- 

tracted by the National Institute of Standards 

and Technology (NIST) to develop a roadmap 

for the architecture and initial key standards 

for an electric power Smart Grid. In his presentation 

entitled, Planning and Implementing 

the Smart Grid in California, Eric highlighted 

the key reasons why we should consider using 

industry standards: consensus on standards 

with nearly complete solutions, avoiding reinventing 

the wheel, learning from industry best 

practices, reducing integration costs, preventing 

single vendor lock-in, and vendors sharing a 

much larger market. 

Industry standards are not meant to stifle innovation; 

they are created to expedite the 

design process and get the solution out in the 

market and implemented quickly. Rather than 

having individual companies generate proprietary 

layers of code that only benefit their specific 

company and market, industry standards 

create a culture of innovation that can propel 

companies more quickly towards innovation. 

On April 27, 2009, the Zigbee Alliance announced 

it would incorporate global IT standards 

from the Internet Engineering Task Force 

(IETF). By using IT standards, products that 

were already developed with proven Zigbee 

smart energy public application profiles could 

be used to further advance the rapid growth 

of home area network (HAN) applications 


Figure 1. Low-power RF chip 

for wireless networking 

being developed for the smart grid in the 

United States. By using products based on the 

same IT standard, electric meters can monitor 

critical energy consumption using devices like 

load control sensors, temperature sensors, outdoor 

lighting sensors and current monitors 

for refrigerators, heating ventilation and air 

conditioning systems (HVAC), pumps and 

lighting systems. Low-cost energy display units 

will allow customers to monitor that activity, 

or leave it up to machine-to-machine (M2M) 

devices to shed demand during critical peak 

times. For example, non-critical tasks, like 

washers and dryers, can be run at night when 

energy costs drop from $.35 a kilowatt-hour 

to $.07 a kilowatt-hour. Let us change the 

mindset where we keep parking garages at the 

airport, large skyscrapers in cities and remote 

parking lots at malls illuminated all night because 

there is a security and liability issue for 

their owners. What if we employed smart motion 

detector sensors and timers with a common 

protocol like 6LoWPAN, Zigbee, SP100 or 

WHART networks so that the lights only came 

on when someone is present? 

Like other semiconductor companies focusing 

on the green energy market Texas Instruments 

is dedicated to solving customer problems 

with the widest range of protocol stacks. As 

early designers with other member companies 

of the ZigBee Alliance, TI saw the need for a

simple way for contractors to reduce cost for 

installing lighting systems. By joining forces 

with other third-party consultants and commercial 

building automation companies to 

create technical working groups, the Zigbee 

Alliance eliminated the stove pipe mentality 

where software developers would create 

proprietary software that would not talk with 

any other device. Interoperability is critical 

for wireless technology for mass market 

deployments. 

Another advantage is that industry-standard 

wireless systems save installation costs for contractors. 

On a typical installation of a wired 

office security system, over 50 percent of the 

installation cost is in pulling wire through 

walls: the ROI on a typical office installation 

of wireless devices can be paid back at a 

fraction of the cost of a wired installation. It 

also costs money to change sensor locations 

in a wired environment. We are all aware of 

the issue of upgrading deployed products with 

software upgrades. The Zigbee Alliance spent 

a lot of time developing network software that 

incorporated feature sets in the stack like overthe-air 

download (OAD). OAD allows an end 

product like a Smart Energy meter to be installed 

in the field and updated remotely with 

function commands that so new software 

features could be installed remotely without 

requiring a contractor to drive out to the 

meter to update feature sets. 

As we move further, the feature sets of standard 

protocols will be incorporated into more and 

more end devices, and the collective efforts of 

NIST, EPRI and the IETF will help companies 

get more products out quicker to the market 

with more features and greater interoperability 

than ever before. Just like the space race got 

simple products like Teflon and the transistor 

radio out to the average household, integrated 

sensor technology will push consumer and industrial 

solutions to market that will lower the 

consumption of energy in the next decade. n 


Editors 

Jürgen Hübner 

phone +49(0)8092-2477413 

fax +49(0)8092-2477429 

jh@iccmedia.com 

Wolfgang Patelay 

wp@iccmedia.com 

Tony Devereux 

devrex@teyboyz.freeserve.co.uk 

For Reader Inquiries and Address Changes 

please contact: 

info@iccmedia.com 

Sales & Marketing Director 

Manfred Blumoser 

phone +49(0)8092-2477411 

fax +49(0)8092-2477429 

mb@iccmedia.com 

Claudia Mellein 

cm@iccmedia.com 

Christiane Lockner 

cl@iccmedia.com 

Sales Office - UK and USA, Benelux, 

Scandinavia 

Blue Sky Communications 

Malcolm Cameron 

Kent Innovation Centre 

Thanet Reach Business Park 

Millennium Way 

Broadstairs Kent CT10 2QQ UK 

phone +44 (0)1843 609357 

fax +44 (0)1843 609358 

mc@blue-sky-communications.com 

Sales Office - Asia 

Jean Cheng, jean@i-media.com.tw 

Vivian Hung, vivian@i-media.com.tw 

Innovative Media Information & Services 

7F-3, No. 26, Sec. 2, Ming-Quan East Rd. 

Taipei 104 Taiwan 

phone +886 2 2563 1186 

Head Office 

ICC Media GmbH 

Rauwagnerstr. 5 

85560 Ebersberg / Germany 

Editorial Office UK 

36a Blackacre Road 

Theydon Bois 

Essex, CM16 7LU 

Copyright© All rights reserved. 

No part of this publication may be reproduced or transmitted 

in any form or by any means without the prior express written 

permission of ICC Media. 

Although we make every effort to present up-to- date, accurate 

information, boards&solutions will not be responsible for any 

errors or omissions or for any results obtained from the use of 

such information. The magazine will not be liable for any loss 

caused by the reliance on information obtained on this site. 

Furthermore, ece does not warrant the accuracy or 

completeness of the information, text, graphics in this magazine. 

The opinions expressed in the articles are those of the 

authors and not necessarily the opinions of the publisher. 

39 December 2010

in PDF Format - Embedded-Control-Europe.com

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?