Embedded Developer: June, 2014 by EEWeb Magazines

E MBEDDED D EVELOPER

Interview with Christian Légaré– Executive Vice President & CTO of Micrium

The New Industrial Revolution: JUNE 2014

Micrium leads the way in IoT development

Code Optimization for ARM Cortex Designing the IoT

Your Guide to Embedded MCUs and Development Tools. Everything youâ&#x20AC;&#x2122;re looking for in one place.

w w w. e m b e d d e d d e v e l o p e r. c o m

built around two high performance 32-bit ARM® Cortex®-M4 RISC processors that operate at a maximum speed of 120 MHz and feature up to 2MB of embedded flash, 304 KB of SRAM, and an on-chip cache for each core. The dual ARM Cortex-M4 architecture allows for the integration of an application layer, communications layers, and metrology functions in a single device. It has options for integrated software metrology or external hardware

With the provision of a physical com layer, the Atmel ATPL230A PLC mod upon the unique and highly flexible S

E MBEDDED D EVEL

COVER INTERVIEW

INTERVIEW WITH CHRISTIAN LÉGERÉ EXECUTIVE VP & CTO OF MICRIUM Interview with Christian Légaré– Executive Vice President & CTO of Micrium

The New TECH ARTICLEIndustrial Revolu

DESIGNING EMBEDDED SYSTEMS FOR THE IOT

IoT is Made of Embedded Devices

Optimizati onCode for ARM Cort izati

Wireless optim Sensor Network

PRODUCT HIGHLIGHT

IoT is not complicated in conception, but it is complex in its execution. Each individual component is simple, but there are many required components for IoT. What is important to understand is that The four separate areas are: even • The Thing (the embedded device) n” if new hardware and software are \ 1 # still under development, we already have • The local network, which moves r0, , 0 ly r data in and out of theD device. This may ”);all the tools we need now to start mbmaking 0 IoT a reality and a majority sethese “A D g asof include a gateway 1, r r asm( to translate in s V u d infrastructure are “MO proprietary communication x: available clare elements y nt a e deMicrium. protocols to the IP family of protocols n bfrom ing s here are four main system components for the Internet of Things:

Micrium leads the way in IoT development

ode Designing the for c tips e 3 v i ions M and t ct technologies / c e carriers have been Popularff networking n 0 isjusti fu waitingofor E ryto x-M eare: rary t investment. de facto standards r ib l o mem d to d / r e a c in C d a e n

• Wireless Sensor Networking d a e sp men suppor of st cod w( omprotocols current leading (especially 6LoWPAN)t use reThe e: po lHTTP, whe thetcreation is reofcthe IoTm ien p s it n , are MQT • Bluetooth Effic a io x t in n e a a a ( 1. r u c t sit CoAP. • Wired Ethernetaand y Wireless tions nt. It cons and m n func sign n teme y e a io r EthernetIn (WiFi) d t t a s c r y u ar d lib ent C cant red lCloud The i a a prim standar iv p ap l qu nifi The Thing the e The Cloud tip is buzz lace e sigis another interesting

MICRIUM EMBEDDED SOFTWARE rep

with

ill b

. This

xam

w is Internet I define a Thing as an etc) computing or eis a c )embedded here network ofistahcloud. The DK. F more tha atoi( system) hat t usecomputing is nothing device (or embedded d tthat cacloud dM e e n v b a r AM that allow y transmits and receives obse information - GCC computers d SR over pileofrsnetworked ent: h an a network for the purpose ragm tasks from your em fprocessing com offload Flas of tcontrolling C e g h in another device or interacting oth with a user. lowsystem. for b e fol A Thing is also a microcontroller—or er th de id s n “Cloud computing” coined touput a microprocessor-based device. h.h> was co incl o has maontsomething t < fvr name that become e e d lud complex. uselaunch h fil The Internet #inc ath. Manyccompanies f ions have m t ) g ( n w try to hide this complexity; Today, the Web runs on hundreds udin that e fu f po Apple’s h o clof ; t n b n I Google Cloud Platform, Microsoft SkyD o * protocols. The IoT will/support hundreds n of others. 2 a, nitiCloud computing/storag itio defiThese int3 Reduc more. We are now massively deploying n u fi e / * e h d t are intended for use with desktop and m pace IP version 6, and IoT is the killerHere Kernel source code f a sh s computers. Embedded g it. ndevelo application that telecommunication s fla personal liand e lbuy i Modular approach –devices. us p Ca something similar * for IoT In cu ;

le ca Local llow • The Internet ); ariab he foNetworks to cal v “r0” ing t • The cloud (desktop, olaptop, s l m(an e u rced C s d A s To design IoT device, local networking a o d n c n r o io is fo a t u o smartphones) or enterprise data ithas c f needs to be analysed closely o y u l d * y r n b t e t as it s a k n in and manipulate le systems that receive ssem it in o ma iabhardware er i arthe a major impact and ays t ng A gist write data (backend data pe von reanalytics) r tyresources Mixi ive w is to o t e software required to build the s t c g l n e e a t ie ff y c s e in a n t e ffi m s h io e device, impacting its cost and energy les (x r ru c t e mo o is t mble iab more 0. of th l inst re fo s on l var er rconsumption. asse and e y ia t , r g c H b is e e in O ne d t g ation loba s s e e sp g r s a U f f . u y g , o e r t p o p er in g e e o u l e s t a g c n a s b r a c u e o e ic t n g o at sh lan van r ca“I define a Thing as an embedded ut a r e acc atdevice dcomputing h em mble ke ad mbly PU b le co and receives system) thatstransmits asse (ornembedded to ta asse g a m information , and the C x+1) amp u s in in y = o y b g m y is : io r d o le ed erepurpose rte device erfcontrolling codin applicat overoastnetwork code forHthe rmanother pof enab uppo owever, erfo t m ) and with are s orainteracting ap user.” s alles why .H nd y tion n r m a is e r s io that il t e is e c p (Op ut th com le. Th ge instru them a ll b ed to r ta b the C e ne ngua g for x\n” ily po a W s in l . C t a s y n l e n in 0, = n” b t dau sem nctio is no itten DR r s r u L y\ e f a “ w = l d d ( a o asm r3, code C , an n” critic the c few n the en in “LDR 1, [r0]\ n” t e a e it r r o w f t r e y l is w #1\ b R n e c “LD r1, sed o al an r1, are u ode ”); D p er b c ] D o 3 y r A l r p “ b [ a r. sem r1, e s l have a b R ix T m “S to m sed asse and s. ta x u u sed piler r e sy n axes g t e m h l t in n i o s y c p is u K he s om hile ..”) d MD are t DK C co d e file w a single C an M C C y Here a G l for lude sem b de inside in C in nt a x o inc ..as o with x is t sm(“ h e sy bly c a a T t m . n _ e r e y o l _ pile e ass his s .c” fi sed t clud Com in a “ iler. T ta x u he to in with om p GCC be e syn e using t c e h d d K t l o u D c f o .”) is file whil ine o the M ssembly y code w ode. gle l a l ax ly c inside a C a sin e of em b b e s in m s d l e a u Synt l ss code o inc i-line “..a x is t mult mbly asm( \n” y nt a asse . s e e l is d fi ne 1 h inclu (“li ld be a “.c” iler. T u n” p m in \ o s h 2 m w o _a e wit ode ine CC c

different communication requiremen able to address all of these segments solution is a significant achievement.

ATMEL’S NEW MODEM GETS SMART GRID DEVICES TALKING

JUNE 2014

CONTENTS

FEATURED ARTICLE

Atmel’s New PLC Modem At the core of Atmel’s smart energy platform is the SAM4C series of products designed for nextgeneration communications for electricity, gas, and water metering systems as well as energy measurement applications. The SAM4C starts with the SAM4C16 and SAM4C8 system-on-chip solutions for smart energy applications and is built around two high performance 32-bit ARM® Cortex®-M4 RISC processors that operate at a maximum speed of 120 MHz and feature up to 2MB of embedded flash, 304 KB of SRAM, and an on-chip cache for each core. The dual ARM Cortex-M4 architecture allows for the integration of an application layer, communications layers, and metrology functions in a single device. It has options for integrated software metrology or external hardware

metrology AFE (analog front end) as well as integrated or external power line carrier (PLC) physical layer solutions. It’s a modular approach that is sure to meet various design needs. As Kourosh Boutorabi, senior director at Atmel Corporation indicated, “We are working with top tier customers worldwide who are trying to develop multiple products for individual markets such as the Spanish, French or U.S. market. These customers need a supplier that addresses all their markets’ requirements. Our solution addresses 90 percent of all of these markets. Every utility has different communication requirements, so to be able to address all of these segments with one solution is a significant achievement.” With the provision of a physical communication layer, the Atmel ATPL230A PLC modem expands upon the unique and highly flexible SAM4CX

FEATURED ARTICLE Atmel’s ATPL230A PLC modem offers PRIME PLC connectivity and support for enhanced PRIME modes. These features allow engineers to concentrate their efforts on application development while ensuring high levels of integration and performance.

platform and offers smart meter architects an unprecedented level of integration and accuracy for single and multichip architecture solutions. “We have recently introduced a new power line communication device to the European and Asian markets,” said Boutorabi. This device gives customers the flexibility to upgrade to a physical layer solution at a later date. A PLC Modem That Speaks PRIME The smart grid implements multidirectional communication channels over existing power distribution networks and incorporates a variety of new alternative energy sources. These sources include solar and wind power as well as new types of electric appliances, such as smart appliances and electric vehicles. But in order for these devices to converse, they have to speak a common language.

ATPL230A, a power line communications interface to Atmel MCUs implementing the PHY layer of PRIME

The PoweRline Intelligent Metering Evolution (PRIME) Alliance, created in 2009, has worked to create an open, future-proof communications PLC-based infrastructure. The PRIME framework provides open-detailed technical specifications to help facilitate the development of fully interoperable smart-grid solutions. Atmelâ&#x20AC;&#x2122;s ATPL230A PLC modem offers PRIME PLC connectivity and support for enhanced PRIME modes. These features allow engineers to concentrate their efforts on application development while ensuring high levels of integration and performance.

In addition to meeting the different components of PRIME specification, key features of ATPL230A include a class D line driver for PLC signal amplification which provides outstanding signal injection efficiency by up to 62 percent. Combined with low-power consumption features, this also allows also for improved thermal behavior, extended long-term reliability and reduced overall power consumption. New transmission modes and frequency band extension also allow for enhanced and more robust power line communications.

FEATURED ARTICLE Evaluation Kits To accelerate the design process, Atmel is also offering the ATPL230A evaluation kit. The kit shows the capabilities of ATPL230A for smartmetering platforms with embedded power line communications. The EK includes a PRIMETM (PoweRline Intelligent Metering Evolution) PHY layer. PRIME is a mature, consolidated and internationally accepted standard for OFDM-based power line communications. PRIME focuses on providing smart grid services over electricity distribution networks. The ATPL230A platform supports the PRIME v1.3.6 version of the specification. On top of that, ATPL230A supports frequency band extension up to 500 kHz, as well as additional robust modes for data transmission. The ATPL230A solution and evaluation kit are available now. To purchase a kit, please contact your Atmel distributor, Atmel sales representative or local Atmel sales office.

â&#x20AC;&#x153;Every utility has different communication requirements, so to be able to address all of these segments with one solution is a significant achievement.â&#x20AC;?

Join Today

eeweb.com/register

EMBEDDED WORKBENCH Dev Kit for the dualcore LPC4357 NXP and element14 present the LPC4357-EVB multimedia evaluation kit, exclusively available from element14. Based on ARM® Cortex™-M4 and Cortex™-M0 processors, the LPC4357-EVB is a high-performance, low-cost solution for developing DSP and MCU applications within a single architecture and development environment. The LPC4357-EVB is equipped with NXP´s dual-core LPC4357 microcontroller. The LPC4357 is an ARM Cortex-M4 based microcontroller for embedded applications and includes an ARM Cortex-M0 coprocessor. It also features 256 Mbit (32 MB) of serial Flash memory from Spansion. The QSPI Flash is connected to the LPC4357’s unique SPI Flash Interface which allows the M4 or M0 core to execute from the QSPI or access large tables of data or images. The Cortex-M4 processor combines the benefits of a microcontroller with high-performance digital signal processing features such as single-cycle MAC, single instruction multiple data (SIMD) techniques, saturating arithmetic and a floating point unit.

QorIQ Starter kit with P10xx The STKP1020 supports all modules of the type series TQMP20xx and TQMP10xx and represents an universal platform for evaluation and development of customer specific platforms for those modules. The STKP1020 includes two PCIe (x1) upgrading plug-in positions, three Gigabit Ethernet ports, as well as two UART e.g. for an easy connection of the bootloader U-Boot with a terminal. A USB 2.0. HOST interface completes the range of interfaces. The use of pluggable Ethernet-PHY´s (FlexiFace) for 100Mbit / 1Gbit enables easy test constructions with different transformer, e.g. optical wave guide.

C8051F064EK Evaluation Kit The C8051F064EK Evaluation Kit is a low cost alternative to the C8051F060DK Development Kit and contains a C8051F064 based evaluation board, USB cable, software CD and full documentation. The evaluation kit includes analog testing software, permitting users to easily test the analog performance (both dynamic and static) of the high precision, 16-bit 1 Msps ADC integrated into the C8051F064. The kit´s software package also includes Silicon Laboratories standard Integrated Development Environment (IDE) development tools.

DESIGNING THE IOT:

Micrium’s embedded systems solutions help drive the industry’s biggest trend Interview with Christian Légaré Executive Vice President & CTO of Micrium

icrium is an industry leading provider of embedded software components. The company’s flagship offering, the µC/OS-II real-time operating system, has become synonymous with reliability and performance, which has led to its adoption in the Mars Curiosity Rover by NASA. As the industry progresses and the demands for embedded systems grow, Micrium is poised and ready to provide back-end support for the new applications that come about. With the rise of the Internet of Things, embedded developers are looking for a dependable way to support increasingly powerful MCUs for device communication. Embedded Developer spoke with Christian Légaré, Executive Vice President & CTO of Micrium, about the ways in which the company plans to help develop the IoT and just how big the IoT will be in the embedded space.

COVER INTERVIEW

When does a developer know when to go from simply developing code to using a real-time kernel? What embedded engineers used to do with smaller microcontrollers is what we call “bare metal,” which means coding directly onto the microcontroller in a super loop [a single thread]. This approach was sufficient for 8- and 16-bit microcontrollers. We are now reaching an inflection point in the industry with 32-bit microcontrollers offering greater performance that is increasingly costeffective, leading to greater adoption. However, coding directly in a super loop for an application dedicated to 32-bit microcontrollers is much more difficult to do because of its increased complexity. This is where the use of a real-time kernel is absolutely mandatory. Even if an application does not need real-time capability, the software architecture that comprises the kernel splits the application into tasks. This crucial feature allows for things like task synchronization to ensure that when you put the tasks together, everything will work seamlessly. Additionally, finding problems within a real-time application is much easier in an embedded system using a multitasking kernel than it is with a super loop.

The reality is that embedded systems developers need to know how the hardware works and how you run the real-time kernel on top of the microcontroller. As the industry transitions to higher-performance 32-bit microcontrollers, using a proven, reliable RTOS and other embedded software components will provide an easier development path to take product to market quickly.

There is a lot of talk in the industry of the Internet of Things. How will the embedded space be involved in its development? The growing importance of the 32-bit microcontroller is directly tied to the Internet of Things [IoT]. Simply put, embedded systems will be critical in the IoT ecosystem. Today microcontrollers are increasingly integrated with more capabilities. This is due in part to the need to connect all of these systems to a network so information can be exchanged between systems—machine to machine— or so we can connect embedded systems to the cloud. This means that in the IoT, the things must talk to other embedded systems or computers on the cloud. To do that, communication stacks are required, but 8- or 16-bit microcontrollers are just too small for the task. Communication

“This means that in the IoT, the things must talk to other embedded systems or computers on the cloud.”

COVER INTERVIEW stacks are larger modules of software, which require a 32-bit microcontroller. For the IoT to take off, embedded systems need to be interconnected, which requires networking stacks. When you get into this type of design is when you need a solid software infrastructure, the cornerstone of which is a real-time kernel plus additional services like TCP/IP, Wi-Fi and Bluetooth stacks. Understanding the underlying embedded systems in these products will allow engineers to maximize the performance of their devices. Another thing that’s happening in the IoT is that we’ll need to develop more and more applications for these embedded systems. Right now, we estimate there are about 450,000 embedded software engineers doing C programming—and that’s not enough. This is driving a tendency right now to move Java into embedded systems programming — providing an estimated 9 million Java developers who could contribute to the development of the IoT. However, even Java developers need to operate on an embedded system. Embedded engineers need to be able to rely on something they can trust that is going to exercise the software properly.

What kind of practical applications do you think are more imminent in the development of the Internet of Things? How big you do you expect the IoT to be in the embedded space? The Internet of Things is not one thing; it’s a lot of things. The IoT will be different depending on what the user needs to do. It will definitely involve embedded or deeply embedded systems communicating and exchanging information with others or with computer servers on larger networks. It will also end up serving a few vertical markets— the first being things that are close to the users and consumers like wearable devices. These can range from fitness monitors to blood pressure monitors to other health-related devices. All of these devices are going to be physically close to the user and will be more visible. But you shouldn’t underestimate the importance of systems that aren’t visible. As such, the second vertical will be more industrial and less visible to users, but both will have a major impact.

“Another thing that’s happening in the IoT is that we’ll need to develop more and more applications for these embedded systems.”

The IoT is reinvigorating the embedded systems market. Cisco, ARM and others are forecasting 50 billion IoT devices in 2025. Out of these, 20 percent are consumer products, such as wearables, smartphones, tablets and so on. This means 40 billion IoT devices will be embedded and deeply embedded systems—a huge market.

are ideally suited for the IoT. Our realtime kernel is scalable between 6 and 24 kilobytes of code, so it fits on any microcontroller. And as an embedded component provider, we recognize we have to have an M2M solution as well as be able to go to the cloud so that we can be the single point of contact for our customers.

There are even some business analysts that are saying that the IoT will be the fourth Industrial Revolution—and I believe them. It’s not going too far to say that the capabilities these technologies deliver will totally transform our society. It offers a huge opportunity for embedded systems, which is contributing to the excitement about the IoT right now. Not a day passes without an announcement for a cloud provider promising to collect all of the data from the devices and store it remotely. Since not everyone understands what an embedded system is or its role, companies like ours provide an M2M IoT solution. Micrium’s experience and long involvement in developing embedded systems, and our software components,

Some market forecasters predict the IoT will be a $20 billion market by 2017, and that aligns with what we’re seeing in the marketplace. Our main concern is to show our customers the best practices for the IoT systems so that it can reach its full potential.

Micrium was recently involved in the Mars rover. Could you talk about that experience and how it may translate to your customers? Our kernel was used in the Mars Curiosity rover to manage the surface analysis module. This module is essentially the laboratory in the rover that takes soil samples for analysis. Clearly for such a demanding application and environment,

“Some market forecasters predict the IoT will be a $20 billion market by 2017, and that aligns with what we’re seeing in the marketplace.”

COVER INTERVIEW a high-quality, reliable kernel was required. When NASA implemented the Micrium kernel, it didn’t change a single thing about our software. It’s a testimony to the quality of the source code in our kernel. To achieve this quality, we take time at the beginning of the process to ensure we design the product properly. This means when it’s released to market, it’s well written and well documented, which allows us to reduce the support burden on our engineers. In fact, the support for the kernels and our other products is really minimal because of their quality, which means our engineers spend most of their time designing and developing new products.

What would you say sets Micrium apart from its competitors? The quality of our product, the documentation and our communication with customers are paramount. While our µC/OS is not open source, it is “source available.” This means the source code for the real-time kernel is available to download from our website. This gives designers access to a proven, reliable kernel as they move through product

“While our µC/OS is not open source, it is ‘source available.’ This means the source code for the real-time kernel is available to download from our website.”

development. Customers need to license the software from Micrium when they decide to use it in a commercial product. Another differentiator is the fact that we can run on virtually any processor architecture. Our products are vendoragnostic in that regard and able to support nearly any project. That said, the No. 1 processor architecture used by our customers right now is ARM. In fact, the ARM processor architecture represents about 50 percent of our business today because it is so prevalent. ARM was the first company to ever license the µC/OS software. Since then, µC/OS has been used on every ARM core architecture up to and including the Cortex M, Cortex R and Cortex A50, meaning we cover the entire processor architecture for ARM. Finally, Micrium CEO Jean Labrosse and I have a solid understanding of where the embedded industry is going, so the company is always ready with quality products to meet emerging requirements. This foresight has been a major contributor to our success.

TECH ARTICLE

Designing EMBEDDED SYSTEMS for the Internet of Things Thinking About

THE INTERNET OF THINGS (IoT) By Christian Légaré, Executive VP and CTO, Micrium Inc.

hat does the phrase Internet of Things mean? It depends a lot

on where you stand in the supply chain. Many have tried to define it, but the definitions are often colored by the needs of their own industries and their own agendas. As a hardware or software engineer, you already understand the essential element: to build products that are interconnected. As such, embedded systems will play—and are playing—a crucial role in the development of the IoT.

IoT is Made of Embedded Devices

here are four main system components for the Internet of Things:

The four separate areas are: • The Thing (the embedded device) • The local network, which moves data in and out of the device. This may include a gateway to translate proprietary communication protocols to the IP family of protocols • The Internet • The cloud (desktop, laptop, smartphones) or enterprise data systems that receive and manipulate data (backend data analytics)

IoT is not complicated in conception, but it is complex in its execution. Each individual component is simple, but there are many required components for IoT. What is important to understand is that even if new hardware and software are still under development, we already have all the tools we need now to start making IoT a reality and a majority of these infrastructure elements are available from Micrium. Local Networks To design an IoT device, local networking needs to be analysed closely as it has a major impact on the hardware and software resources required to build the device, impacting its cost and energy consumption.

“I define a Thing as an embedded computing device (or embedded system) that transmits and receives information over a network for the purpose of controlling another device or interacting with a user.”

TECH ARTICLE

Wireless Sensor Network

Popular networking technologies and de facto standards are: • Wireless Sensor Networking (especially 6LoWPAN) • Bluetooth • Wired Ethernet and Wireless Ethernet (WiFi)

carriers have been waiting for to justify their investment. The current leading protocols supporting the creation of the IoT are HTTP, MQTT and CoAP. The Cloud

The Thing I define a Thing as an embedded computing device (or embedded system) that transmits and receives information over a network for the purpose of controlling another device or interacting with a user. A Thing is also a microcontroller—or microprocessor-based device. The Internet Today, the Web runs on hundreds of protocols. The IoT will support hundreds more. We are now massively deploying IP version 6, and IoT is the killer application that telecommunication

The Cloud is another interesting buzzword. A network is a cloud. The Internet is a cloud. And cloud computing is nothing more than an array of networked computers that allow you to offload processing tasks from your embedded system. “Cloud computing” was coined to put a simple name on something that has become very complex. Many companies have launched services that try to hide this complexity; Apple’s iCloud, Google Cloud Platform, Microsoft SkyDrive, and others. These Cloud computing/storage systems are intended for use with desktop and mobile personal computers. Embedded developers need something similar for IoT devices.

“What is important to understand is that even if new hardware and software are still under development, we already have all the tools we need now to start making IoT a reality and a majority of these infrastructure elements are available from Micrium.”

The IoT from the embedded system point of view With as many as 80% of IoT devices expected to be embedded or deeply embedded systems, there will be a transition to the use of 32-bit processors for communication. This is because when these microcontrollers run an RTOS they are more cost-effective than when running a high-end operating system like Linux, Android or Windows. Taking sensors as an example, it will not be uncommon to see two microcontrollers; an 8-bit or 16-bit microcontroller for the analog world interface (sensors and actuators) that offers better power consumption, and a 32-bit to handle communications (6LoWPAN, Bluetooth, WiFi, wired Ethernet…). These systems will be mainly programmed in C and C++. But, because of the very large number of devices, an “app store” business model makes sense. This is driving the use of Java for the IoT, as it allows for dynamic loading/ unloading of applications—and has the developer manpower needed to develop and deploy an IoT app store. However, pure Java is too large in code and RAM requirements for microcontrollers. This

means solutions like Micrium’s Java Virtual Machine are needed, as it can run within 40 KB of code and with very efficient memory management. Conclusion The requirements for IoT device communication dictate the requirements for the device’s software. Any one of the above-mentioned communication stacks, together with the application implemented in the device, represents a significant amount of software. Of course, any discussion of IoT would not be complete without looking into the Internet and Cloud services. Once we have an IoT device transmitting or receiving data encapsulated in an IP packet, we now have to see how this data can be stored, analyzed and used to create more value. Ultimately, this is why any IoT device design should use proven building blocks for the Thing hardware and software platform, the Internet IoT protocols and the Cloud, and back-end services so that the designer can concentrate on crucial product differentiators and reduce time to market.

TECH ARTICLE

Join Today

eeweb.com/register 23

Reduce your time to market Kernel source code available for download Modular approach â&#x20AC;&#x201C; buy and use only what you need

PRODUCT HIGHLIGHT

速

Embedded Software Reduce your time to market with our comprehensive modular real-time operating system (RTOS) ideally suited to any vertical market.

Proven embedded software components you can rely on.

µC/OS-III® real-time kernel featuring unlimited application tasks and an interrupt disable time of near zero

µC/TCP-IP™: a compact, high-performance TCP/IP stack featuring IPv4 & IPv6

Micrium’s µC/TCP-IP networking stack now supports IPv6

µC/OS-III is a highly portable, ROMable, scalable, preemptive, real-time, deterministic, multitasking kernel for microprocessors, microcontrollers and DSPs. µC/OS-III’s footprint can be scaled to contain only the features required for a specific application (typically 6-24 KB of code space residing in memory). Proven on nearly every processor architecture in the industry, the μC/ OS-III real-time operating system offers unprecedented ease of use, and is delivered with complete 100% ANSI C source code and in-depth documentation, as is provided for all Micrium embedded software components. Ports are available for download from the Micrium website to help you get your products to market faster.

The μC/TCP-IP TCP/IP protocol stack is optimized for embedded systems, and features dual IPv4 and IPv6 support. Built from the ground up with Micrium quality, scalability and reliability, μC/TCPIP enables the rapid configuration of required network options to minimize time to market. The source code for μC/TCP-IP is an extremely robust and highly reliable TCP/IP solution. μC/TCPIP is designed to be certifiable for use in avionics, compliant for use in FDA-certified devices, and in other safety-critical products. A trial version is available for download from our website for a large number of MCUs.

IPv6’s addressing scheme provides more addresses than there are grains of sand on Earth—some have calculated it could be as high as 1030 addresses per person. With IPv6, it’s much simpler for an embedded device to obtain a global IP address, which enables efficient peer-to-peer communication. If you’re already using Micrium’s µC/ TCP-IP, you’ll find integrating the new IPv6 stack into an existing design is straightforward. If you’re a new user of µC/TCP-IP, you’ll benefit from our focus on ease of use and top-notch documentation. µC/TCP-IP will help you get your product to market faster.

PRODUCT HIGHLIGHT Micrium’s real-time µC/USB Host™ software stack: Designed for use in embedded systems with a USB Host or OTG controller

Micrium µC/USB-Device™: A compact, reliable highperformance solution for embedded systems equipped with a USB device controller

μC/FS™: A compact, reliable, high-performance and thread-safe embedded file system for microprocessors, microcontrollers and DSPs

μC/USB Host is a USB Host software stack that includes many class drivers (MSC, HID and CDC ACM). The stack requires a kernel. μC/USB Host uses a modular architecture with three software layers between the application and the hardware: the class driver; Host core; and Host controller driver.

µC/USB-Device supports several standard device classes (audio, CDC ACM and CDC EEM, HID, MSC, PHDC). A vendor class is also provided for developing vendorspecific USB devices. Thanks to a hardware abstraction layer, you can easily port μC/USB-Device to any new USB device controllers by simply modifying existing hardware access routines. μC/ USB-Device uses a modular architecture with three software layers between the application and the hardware: the device controller driver; device core; and class layers. The CDC EEM class is also a recent addition to the product, offering transport of Ethernet frames over USB.

Micrium’s µC/FS file system can access multiple storage media through a clean, simple API. It supports the FAT file system for interoperability with all major operating systems. An optional journaling component provides fail-safe operation, while maintaining FAT compatibility. As with all Micrium embedded software components, μC/FS is based on clean, consistent ANSI C source code, with extensive comments describing most global variables and all functions. The memory footprint of μC/ FS can be adjusted at compile time based on required features and the desired level of runtime argument checking. For applications with limited RAM, features such as cache and read/ write buffering can be disabled; for applications with sufficient RAM, enabling these features improves performance.

Micrium’s µC/USB-Device stack now offers an audio class that allows for building devices manipulating music, voice and other sound types targeting the general consumer audio market (for example, headset, speaker and microphone).

“Micrium’s µC/USB-Device stack now offers an audio class that allows for building devices manipulating music, voice and other sound types targeting the general consumer audio market (for example, headset, speaker and microphone).”

Micrium Embedded Tools 28

Use µC/Probe Graphical Live Watch™ to graphically visualize the internals of any embedded system effortlessly

Reduce troubleshooting time and improve software quality, performance and reliability with the µC/Trace™ RTOS event analyzer

Micrium’s µC/Probe is a Windows application that allows you to read and write the memory of any embedded target processor during run-time, and map those values to a set of virtual controls and indicators placed on a graphical dashboard. μC/Probe can also extend the capabilities of debugging software when both are run at the same time, allowing instant control over global variables in a real-time and nonintrusive way. When using an ARM Cortex-M or a Renesas RX via a JTAG probe, µC/ Probe is totally nonintrusive. No code needs to be added to an application to read/write global variables and MCU registers.

µC/Trace is an advanced tool for run-time diagnostics of embedded systems running μC/OS-III. It gives developers unprecedented insight into run-time behavior, allowing for reduced troubleshooting time and improved software quality, performance and reliability. Spend more time developing valuable new features and deliver high-quality embedded software on-budget with µC/Trace.

PRODUCT HIGHLIGHT

“Part II of each book describes practical, working applications for embedded medical devices built on popular microprocessors.” Learn the essentials of real-time operating systems, networking and embedded TCP/IP and USB device stacks. A leader in real-time operating system development and education, Micrium has published a number of comprehensive and detailed books that delve deeply into the operation of real-time kernels and other embedded components. All books feature hands-on working projects to get applications running quickly.µC/OS-III

µC/OS-III

μC/TCP-IP

µC/USB-Device

Part I of the µC/OS-III book walks through various aspects of its implementation and usage. Part II of each book provides practical, working applications for a popular microcontroller. Available titles include Freescale Kinetis, Infineon XMC4500, NXP LPC1768, Renesas RX62N, Renesas SH7216, STMicroelectronics STM32 and Texas Instruments Stellaris.

Part I of the µC/TCP-IP book includes an overview of the basics of the Internet protocol and walks through various aspects of μC/ TCP-IP implementation and usage. Part II of each book describes practical, working applications for embedded medical devices built on popular microprocessors, including the Freescale Kinetis, Renesas RX62N, Renesas SH7216, Texas Instruments LM3S9B92 and STMicroelectronics STM32.

Part I of this book describes the inner workings of USB using μC/ USB-Device as a reference. Part II demonstrates how μC/USBDevice stack can be used as the foundation to build a USB device that relies on a combination of proven hardware and software platforms.

Micrium’s advantages are not just in our source code; they’re in the documentation, technical support and our exceptional technical training. Come learn with us. Micrium offers free, hands-on training at our facility in Weston, Florida. With the purchase of any uC/OS-II or uC/OS-III software license, you can benefit from three full-day sessions. Micrium’s training sessions are packed with valuable embedded software content and provide developers an ideal means of preparing for their projects.

About Micrium Micrium is a global RTOS leader and a top choice of embedded engineers building microprocessor, microcontroller and DSP-based devices. Our commercial RTOS components are the preferred solution over open source and competitive alternatives.

The leading commercial RTOS for ARM MCUs • First kernel ported to ARM • First kernel ported to the Cortex-M

Committed to ARM for Life www.micrium.com

OPTIMIZATION

TECHNIQUES in Cortex Processor Architecture

esan n n a ha G h Bala s A By hes a M and

TECH ARTICLE

[

Analysis at the compiler level

]

The purpose of this article is to familiarize the reader with few techniques that can be integrated in the code for efficient code optimization while designing projects based on ARM Cortex TM -M3 and ARM Cortex TM -M0 architecture. The compilers that are focused on throughout this article are GCC (GNU Compiler Collection) and MDK (Microcontroller Development Kit). After reading this article, the reader will have a better understanding of: 1. The chief factors responsible for memory consumption in an embedded design 2. How to effectively optimize memory (Flash and SRAM) for size and speed in constrained designs 3. Several methods for optimizing for speed in a design 4. How to select the best compiler to fit a design

Compiler Compilers translate high level language (C or C++) code into assembly instructions which the processor (Cortex TM -M3, Cortex TM -M0 etc) supports. Most developers don’t prefer coding in assembly language directly as it is not as user friendly as C coding. In the case of the Cortex-M series, the most commonly used compilers are GCC, MDK, and RVDS (RealView Development Suite).

Cortex Processors The ARM Cortex™ -M3 processor, the first of the Cortex generation of processors released by ARM in 2006, was primarily designed to target the 32-bit microcontroller market. The Cortex-M3 processor provides excellent performance at low gate count and comes with many new features previously available only in high-end processors. The Cortex-M3 continues to address the requirements of the 32-bit embedded processor market with its performance efficiency, low power consumption, improved code density, and wide choice of development tools, among others. The idea behind ARM Cortex TM -M0 was to create the smallest, lowest power processor possible, while remaining upward compatible with the higher-performance ARM Cortex-M3. ARM

announced the Cortex-M0 processor in February 2009, and it achieved its goals. The resulting design is just 12,000 logic gates in minimum configuration, as small as an 8-bit or 16-bit processor, but it is a full 32-bit processor that incorporates advanced technologies with many compelling benefits over 8-bit or 16-bit devices. The ARM Cortex-M3 and -M0 are, however, cores that have been developed by ARM and not directly available on the market. Rather, processor manufactures license the core and integrate their own IP to create an off-the-shelf product for use in applications. For example, PSoC (Programmable System On Chip) from Cypress offers four MCU options for 8-bit and 32-bit applications, ranging from the cost-optimized 8-bit M8C to the highperformance ARM Cortex™-M3. PSoC is also the world’s first programmable embedded design platform that integrates discrete analog and programmable logic along with memory and a microcontroller. Easy to use software tools, like our PSoC Creator Integrated Design Environment, simplify the design and debug of analog front ends and digital glue logic while accelerating complete system designs. PSoC Creator support compilers like GCC, MDK and RVDS for the development of applications based on PSoC® 4 and PSoC® 5LP.

“The Cortex-M3 processor provides excellent performance at low gate count and comes with many new features previously available only in high-end processors.”

TECH ARTICLE

Cortex -M0

Cortex -M3

Figure 1. Cortex CPU Architectures

Registers in Cortex M3 and M0

•

Link register (R14) : For fast return from function calls

Cortex-M0 and Cortex-M3 registers are very similar, as Figure 1 shows.

•

Program counter (R15): The program counter is the current program address. This register can be written to control the program flow

•

Program status register (PSR) : Contains instruction results such as zero and carry flags

•

Interrupt mask register: Blocks all interrupts apart from the non maskable interrupt (NMI) and the hard fault exception

•

Control register: Define privileged status and stack pointer selection

The register set and instruction set are the basis for a powerful, efficient C engine. All registers are 32-bit wide. There are 12 general-purpose registers (low registers R0 – R7 have more extensive instruction support). Special registers include: •

•

Dual stack pointers (R13): The Cortex TM -M3 and M0 two stack pointers (They are banked so that only one is visible at a time. The two stack pointers are as follows: Main Stack Pointer (MSP): The default stack pointer, used by the operating system (OS) kernel and exception handlers Process Stack Pointer (PSP): Used by user application code

Cortex-M3 has more features in stack management, and in the PSR, interrupt, and control registers. The Cortex-M3 also has a more extensive instruction set, including divide (UDIV, SDIV), multiply and accumulate (MLA, MLS), saturate (USAT, SSAT), and bitfield instructions.

Mixing Assembly and C One of the most effective ways to make your code shorter, faster, and more efficient is to write it in assembly language. Using assembler may also enable you to take advantage of special instructions that are supported by the CPU but are not used by the C compiler. However, coding in assembler can be daunting for all but the smallest applications, and the code is not easily portable. This is why most code is written in C, and assembly language instructions are used only for a few critical functions. We need to have a proper balance between the code written in C and assembler. Here are the syntaxes used to mix assembly code within C in GCC and MDK compilers.

GCC Compiler Syntax asm(“..assembly code..”) is the syntax used to include assembly code inside a C file while using the GCC compiler. This syntax is to include a single line of assembly code within a “.c” file. The syntax for multi-line assembly code would be

asm(“ADD r0, r0, #1\n” “MOV r1, r0”); A local variable can be declared using assembly instructions using the following syntax: register int *foo asm(“r0”); Here foo is the integer type variable and it is forced to occupy register r0. Here is sample code accessing global variables (x and y) and performing a mathematical operations on them (Operation performed: y=x+1) asm(“LDR “LDR “LDR “ADD “STR

r0, r3, r1, r1, r1,

=x\n” =y\n” [r0]\n” r1, #1\n” [r3]”);

MDK Compiler _ _ asm(“..assembly code..”) is the syntax used to include assembly code inside a C file while using the MDK compiler. This syntax is to include a single line of assembly code within a “.c” file. The syntax for multi-line assembly code would be

asm (“line 1\n” “line 2\n” “line 3\n” ... “line n”);

_ _ asm (“line 1\n” “line 2\n” ... “line x\n”); or

Each line represents an assembly instruction.

_ _ asm { line 1 line 2 ... line x}

Here is an example where we increment the R0 register by 1 and move the value stored in r egister R0 to R1:

TECH ARTICLE

Effective tips for code optimization in Cortex-M0/ M3

This logic is also true for the following code fragment:

1. Efficient use of standard library functions In many situations where code space/ memory is a primary design constraint, it is recommended to replace standard library functions (example: pow(), atoi() etc) with the equivalent C statement. It can be observed that there will be significant reduction in Flash and SRAM because of this. This tip is applicable for both the compilers- GCC and MDK. For example, consider the following C fragment:

#include<stdlib.h> /* Including stdlib.h header file * char str[]=”12345”; int val=atoi(str); /* Converting a string to an integer */

#include <math.h> /* Including math.h file to include the definition of the functions used from it. Here the definition of pow() function occupies flash space*/uint32 a, b; a = 5; b = pow(a,3); /* Calling function pow() and passing arguments. Involves additional instructions to pass arguments and branch to the function */ This small code fragment consumes too much of SRAM and FLASH when compiled using both the compilers with either the M3 and M0 architectures. Statistics shows that a test of the above code snippet with the GCC compiler on a PSoC 4 (a programmable SoC with Cortex-M0 core) consumes 112 bytes of SRAM and 13192 bytes of Flash. There can be a significant code reduction if the above code fragment is replaced with: b = a * a * a; Under similar test conditions as discussed before, the above code snippet consumed 16 bytes of Flash and no SRAM, providing a dramatic reduction in code-size.

Here also we can preserve memory if the code is replaced with: char str[]=”12345”; int val= 0,i; for(i=0;str[i]!=’\0’;i++) val=val*10+str[i]-‘0’; /* Converting the string to an integer using for loop */ Thus, we have to be careful when using standard library functions, especially in memory constrained applications. As far as possible, replace the standard library functions with the equivalent C function. 2. Usage of Packed attributes Structures in a high-level language such as C can be classified into two types: packed, and unpacked. By default, structures are stored in unpacked format by both the GCC and MDK compilers. Unpacked structures align the addresses of individual elements in the structure according to the variable’s data type. Here are the alignments for some of the commonly used data types: • A char variable(one byte) is 1-byte aligned. • A short or int variable (two bytes) is 2-byte aligned. • A long or float variable (four bytes) is 4-byte aligned. • Any pointer (four bytes) is 4-byte aligned.

Sometimes, there will be wasted memory between the elements of the structure because of the address alignment. If you want to get rid of this memory wastage by making the address of the members independent of the data type to which they belong to, then you need to force the structure to be “packed”. Consider the following code fragment where the structure’s members are shown along with the addresses assigned to each of them: struct { uint8 uint8 uint32 uint16 };

foo // unpacked structure membera; memberb; memberc; memberd;

// // // //

membera memberb memberc memberd

@20007fc8 @20007fc9 @20007fcc @20007fd0

To pack a structure, add the packed attribute as shown below: struct foo // packed structure| { uint8 membera; // membera @20007fc8 uint8 memberb; // memberb @20007fc9 uint32 memberc; // memberc @20007fca uint16 memberd; // memberd @20007fce } _ _ attribute _ _ ((packed));

and 0x20007FCC). It is always recommended to use packed structures to save SRAM (consecutive addresses for member b and member c). Apply the packed attribute to the structure definition, and not to any instance of the structure. Also, do not use typedef with packed structures as both the compilers would then not take the structure as a packed structure. 3. Mixing assembly and C – Making use of efficient instructions which compilers do not normally use There are certain instructions that compilers do not generate by default. We can take advantage of using these instructions as inline assembly by mixing assembly and C. Saturation instructions are a good example that fall under this category. The Cortex TM-M3 supports two instructions that provide signed and unsigned saturation operations — SSAT and USAT (for signed data type and unsigned data type, respectively) — which are normally not generated by the compiler. Saturation is commonly used in signal processing for operations such as signal amplification. When an input signal is amplified, there is a chance that the output will be larger than the allowed output range. If the value is adjusted simply by removing the unused MSB, an overflow result will cause the signal waveform to be completely deformed. Saturation operations do not prevent the distortion of the signal. However, the amount of distortion is greatly reduced in the signal waveform as shown in Figure 2 .

You can also follow the below style for MDK: packed struct foo { … } ; As you can see in the above example, in an unpacked structure, consecutive memory locations may not be allocated for members. For example, if a uint8 and a uint32 are declared consecutively, the uint8 member may use 4 bytes (gap between address 0x20007FC9

Figure 2. Signal structure with and without saturation

TECH ARTICLE

A common scenario where these instructions can be used is with ADCs (Analog to Digital converters). Suppose we are using a 16-bit ADC and want to read only 12 bits, then we could use if-else conditional checks to perform the saturation. This can be easily done using a single assembly saturation instruction without much complexity. On the other hand, if we are not using the if-else conditional checks, then the signal may be distorted as shown above in Figure 2.

5. Use inline assembler in speed-critical sections: Assume that we are using a Cortex TM-M based MCU/ SoC with memory mapped I/O. Consider a situation where we need to define a function which toggles a digital output pin of the MCU/ SoC at the highest frequency, while retaining the status of other pins in the same port. In this case, the normal C code definition to toggle a pin using the port address and the bit mask as inputs would be as follows:

SSAT and USAT Instructions

void tglPin(long *portAdd, uint8 bit _ mask) { /* Toggling the pin represented by bit mask in the port pointed by portAdd */*portAdd ^= bit _ mask; }

The SSAT instruction applies the specified shift, then saturates to the signed range −2n–1 ≤ x ≤ 2n–1−1, while the USAT instruction applies the specified shift, then saturates to the unsigned range 0 ≤ x ≤ 2n−1. Details on these instructions can be obtained from the Cortex-M3 Generic User Guide. The syntax for using USAT(or SSAT) instruction would be: usat <source_reg>,<no of bits>,<dest_reg> Here <source_reg> and <dest_reg> can be any register from r0 to r14 and <no of bits> signifies the total number of bits to which the result should be saturated. 4. Limiting parameters passed to a function: Both the GCC and MDK compilers use registers r0-r3 to pass the first four arguments (left to right) to a called function and all additional arguments to be passed make use of the stack. If you are looking for code size optimization as well as speed optimization, it is highly recommended to define functions in such a way that less than 4 arguments are passed so that we can avoid the use of the stack and loading data from memory.

This function takes the port address and bit mask corresponding to the particular pin to be toggled as inputs. The same function can be defined in assembly as follows: void tglPin(long *portAdd, uint8 bit _ mask) { asm(“LDRB r3, [r0]\n” “EOR r3, r3, r1\n” “STRB r3, [r0]”); } Irrespective of the compiler, in Cortex TM -M0 and Cortex TM -M3, the passed arguments are stored in registers r0-r3 from left to right. Hence *portAdd can be fetched from register r0 while bit_mask can be fetched from register r1.

Note: The return value of any function is by default stored in r0 by both the GCC and MDK compilers.

If this function is called in a finite or an infinite loop without any delay in between, the maximum achievable switching frequency when the function is defined in assembly would be many times faster than the function defined in C. For similar speed critical sections, it is advisable to define those sections in inline assembly. 6. Use inline assembler in size-critical sections: As discussed in point [3], there are many useful instructions in the Cortex TM-M3 / M0 architecture which the compilers may not use by default. These instructions would replace a series of assembly instructions and thus would help us in reducing the code size. There are various instructions like MLA (multiply and accumulate) which can replace a multiplication and an addition instruction and would be useful for signal processing applications. 7. Preferable to use MDK compiler for both speed as well as size optimization: Consider the following example,

The table below shows how the GCC and MDK compilers translate the above code into assembly when both are set to size/ speed optimization. The device used for testing is the Cypress PSoC 4/ PSoC 5LP. The example below (Table 1) shows how a conditional loop would behave across different compilers and optimization levels and demonstrates the behavior only for a small number of iterations. If you interpolate how the above table would be for a loop with a large number of iterations say 20, 50, 100 etc, then you can note that the GCC compiler does extreme optimizations (i.e) it does not worry about the speed of the code when it is set to size optimization and vice versa. With the MDK compiler, in contrast, both size and speed remain the same irrespective of the number of iterations in the loop. Hence in an application where you are looking for both size as well as speed optimization, it is better to choose GCC.

for(i=0; i<3; i++) LCD _ PrintNumber(i); Table 1.

Compiler

Size Optimization

Speed Optimization

GCC

movs r4, #0 <main+0x8> uxth r0, r4 adds r4, #1 bl <LCD _ PrintNumber> cmp r4, #3 bne.n <main+0x8>

movs r0, #0 bl <LCD _ PrintNumber> movs r0, #1 bl <LCD _ PrintNumber> movs r0, #2 bl <LCD _ PrintNumber>

MDK

movs r4, #0 <main+0x8>: uxtb r0, r4 adds r4, #1 bl <LCD _ PrintNumber> cmp r4, #3\ bne.n <main+0x8>

movs r4, #0 <initialize _ psoc+0x72>: mov r0, r4 bl <LCD _ PrintNumber> adds r4, r4, #1 uxtb r4, r4 cmp r4, #a bcc.n <initialize _ psoc+0x72>

TECH ARTICLE

8. Placing variables in bit addressable regions for bitwise operations: CortexTM-M3 has a bit-band feature, where accessing an address in an alias region (addresses 0x22000000-0x23FFFFFF) results in bit-level access in the corresponding bit band region (addresses 0x20000000-0x200FFFFF). This lets you quickly set, clear, or test a single bit in the bottom 1 Mbyte of the region. One advantage of this would be that you can easily access the bits for performing bit-wise logical operations. By the normal method, you may have to mask the concerned bit for performing the operation, but with this method you can directly access bits. Some applications where bit-band accessible regions would be useful would be in cases where individual bits in this memory section have to store the status of events.

Making use of bit-addressable regions would help in size as well as speed optimization. To perform this operation, it is recommended to define custom sections with these specific addresses in he LD (Linker Script) file in the case of the GCC compiler while in the SCAT (scatter) file in case of the MDK compiler. 9. Optimum use of function pointers: It is a common practice to access functions using their respective function pointers. For example, consider the two code fragments given below to call a function using pointers: As far as the optimization factor is concerned, Method 1 is preferable over Method 2. Using Method 2, we are actually forcing the compiler not to optimize the function definition. However, Method 1 would optimize the function definition when you are using size/speed optimizations. This is useful when you want to optimize functions in size/speed critical applications.

Table 2.

Method 2

Method 1 uint8 Fun(uint8); // Inside main() MyData=(*Fun)(10); // Function Definition uint8 Fun(uint8 x) { return(x + 5); }

uint8 Fun(uint8); // Inside main()MyFunPtr = &Fun; MyData = (*MyFunPtr)(10); // Function Definition uint8 Fun(uint8 x) { return(x + 5); }

References

Authors

1. Cortex-M3 Technical Reference Manual: http://infocenter. arm.com/help/topic/com.arm.doc.ddi0337i/DDI0337I_ cortexm3_r2p1_trm.pdf

Asha Ganesan earned her BE in Electronics and Communication Engineering from College of Engineering Guindy, India. She is currently working as an Applications Engineer at Cypress Semiconductor on PSoC 3/4/5LP based projects and assisting customers in their designs.

2. Cortex-M0 Technical Reference Manual: http://infocenter. arm.com/help/topic/com.arm.doc.ddi0432c/DDI0432C_ cortex_m0_r0p0_trm.pdf 3. Cortex-M3 Generic User Guide : http://infocenter.arm.com/ help/topic/com.arm.doc.dui0552a/DUI0552A_cortex_m3_ dgug.pdf 4. PSoC速 - Programmable System-on-Chip: http://www.cypress.com/psoc/?source=CY-ENG-HEADER 5. PSoC Creator :www.cypress.com/psoccreator/

Mahesh Balan earned his BTech in Electronics and Communication Engineering from Model Engineering College, India. He is currently working as an Applications Engineer at Cypress Semiconductor on PSoC 3/4/5LP based projects and assisting customers with their designs.

TECH ARTICLE M o v i n g To w a r d s a

David Elien VP of Marketing & Business Development, Cree, Inc.

Clean Energy

Let There Be

LIGHT

FUTURE

How Cree reinvented the light bulb

— Hugo van Nispen, COO of DNV KEMA

Cutting Edge

SPICE

Modeling

MCU Wars 32-bit MCU Comparison

Cutting Edge Flatscreen Technologies

New LED Filament Tower

View more EEWeb magazines— Click Here

Power Developer O ct o b er

201 3

From Concept to

Reality

Sierra Circuits:

Designing for

Durability

A Complete PCB Resource

Wolfgang Heinz-Fischer Head of Marketing & PR, TQ-Group

TQ-Group’s Comprehensive Design Process

Freescale and TI Embedded Modules

Ken Bahl CEO of Sierra Circuits

PLUS: The “ Ground ” Myth in Printed Circuits

PCB Resin Reactor

ARM Cortex Programming

Low-Power Design Techniques