Page 1



Issue 66 October 2, 2012

Ranjit Deshpande

Vice President of Engineering Renesas Electronics America Electrical Engineering Community Visit


Experts Exchanging Ideas Every Day. VISIT DIGIKEY.COM/TECHXCHANGE TODAY! Digi-Key is an authorized distributor for all supplier partners. New products added daily. Š 2012 Digi-Key Corporation, 701 Brooks Ave. South, Thief River Falls, MN 56701, USA




Ranjit Deshpande RENESAS ELECTRONICS AMERICA Interview with Ranjit Deshpande - Vice President of Engineering

Featured Products


The Highs and Lows of Resistance Measurements: Can You Trust Your Test? Pt. 1


BYJONATHAN TUCKER WITH KEITHLEY INSTRUMENTS How characterizing resistances lower than 10 ohms or higher can be significantly more complex than it seems and how this process can be simplified.


What’s In a Name? BY DAVE VANDENBOUT WITH XESS CORP. Why finding a good set of naming rules for variables in your HDL code should be considered before everything else.


RTZ - Return to Zero Comic





De Re

4 26

EEWeb | Electrical Engineering Community EEWeb | Electrical Engineering Community



eshpande enesas

Renesas Electronics America

Renesas Electronics America is a leading semiconductor company that relies on all facets of their technology to come up with unique solutions. We spoke with the vice president of engineering, Ranjit Desphande, about their flagship microcontroller products, maintaining Renesas’ reputation of integrity and quality and how his experience in other fields helps bring a fresh perspective to Renesas’ ever-evolving product line.


5 27

EEWeb PULSE Tell us a little bit about yourself. How did you get into electrical engineering? It goes back to school, when I first encountered the BBC Micro computers that my school had. I started playing with these computers in an environment where we didn’t really have much in terms of structured instruction. I became fascinated with the fact that I could move a square block of pixels across a monitor from left to right and right to left. That really sparked my interest. Later on in school, I took an optional course in electronics, so I got started in 11th and 12th grade building little circuits that had 555 timer ICs. I went on to do my Bachelor’s and Master’s in Electrical Engineering and Computer Science. Could you tell us more about your career prior to working at Renesas? I started off in a company called SCO (Santa Cruz Operation), which is a Unix software provider that famously sued IBM for patent and copyright infringement. I started working on Unix kernel development. Operating systems have always been my area of interest. After that, I moved on to join Sun, but the most significant part of my career was starting my own company back in 2000, which was in the networking software domain. We did software for home networking devices like Access Point, DSL gateways, Ethernet gateways and with customers like Motorola and Linksys. In 2007, my company was acquired by 2Wire which is in the DSL/Gateway space. What is your role at Renesas? Coming from the outside, a lot of today’s customers expect that the semiconductor companies


Signal Chain will provide anywhere from 40 to 70 percent of their product solution as a building block. My role is to really foster the development of these solutions based on our microcontrollers and microprocessors, analog and power devices and add software to the mix as well. The focus for me is to go after these solutions. What kinds of solutions have you targeted? The biggest area for us is the signal chain. What I mean by that is everything starting from the sensor. If you were to draw a mental picture, you have sensors that measure real world analog input. The signals from those sensors get conditioned and get fed to a microcontroller or microprocessor, which then analyzes the data and decides to take some action based on that input. As a result of that action, you can activate some sort of actuator somewhere on the other side. This signal chain is the driving principle behind any of our solutions. We’ve worked on several solutions in the last year. Some of the best examples are focused on LED lighting, given that we have some innovative solutions that make use of microcontrollers

EEWeb | Electrical Engineering Community

to do dimming for LED lights. Typically, if you go to Home Depot or a home improvement store and buy a dimmer that traditionally works with the incandescent bulbs, they don’t tend to work that well with LED lights or CFL bulbs. We’ve come up with some very innovative solutions that use not just analog and power parts, but also a microcontroller that can adapt dynamically to the characteristics of the bulb that is being dimmed. We’ve also created solutions around motor control, which is another significant area of interest, given our customer profile in appliances and automobiles. All of these are at the heart of several sub-systems for motor controls. What we’ve done is taken some of our leading-edge flagship 32-bit microcontrollers and designed a solution with IGBT or power MOSFETs that are also manufactured by Renesas and put together some sophisticated Vector Control algorithms. The result is presented as a complete solution to customers that can then build their particular product or their intellectual property on top of that. It’s another example of going from not just the microcontrollers, but also from the analog and power domain.

INTERVIEW What can you tell me about the culture at Renesas? Worldwide, Renesas is known for integrity, honesty and quality. That’s something that I’ve known by looking from the outside in—I was always impressed by how Renesas was always good at doing what they said they would do. Not just in terms of delivering products that met specifications, but simple stuff like getting your purchase orders paid on time. From within

engineers don’t feel disconnected from the upper management. Often times, they view me as just another engineer who is able to listen to their arguments or offer feedback. I am also trying to encourage our engineers to think about solutions when they are trying to address problems. We will often have something that we are working on that is specific to a single customer. What I try to tell our engineers is not to view that as a one time project,

the NEC Electronics and Renesas Technology semiconductor business. That particular part has been extremely successful for us and we continue to bring in different models and different features on that RL78 microcontroller line. We are going to see more and more options for that part in different areas like automotive, where it has a lot of potential for increasing the efficiency and increasing the amount of features in automotive

“Coming from the outside, a lot of today’s customers expect that the semiconductor companies will provide anywhere from 40 to 70 percent of their product solution as a building block. My role is to really foster the development of these solutions based on our microcontrollers and microprocessors, analog and power devices and add software to the mix as well.” the company, what I found is that it’s a culture that permeates every organization. I tried to instill some of that global culture in the team here in the U.S. In addition to that, my style of management coming from a start-up is an open style, meaning every engineer within the organization is absolutely welcome and encouraged to walk in my office and talk about any project they are working on, discuss ideas or bring complaints to my attention. The thing I enjoy the most in this atmosphere is the ability to bounce ideas off of each other. Even though I have the position of VP of engineering, I am still very hands-on—it’s always been the way I am. There are a lot of areas where I like to work on the designs with my engineers, which I feel creates a much better relationship in the management chain so that

rather to try and take a solution for a particular customer and generalize it for applications to future products. What are some of the new products you are developing? We have had two very successful product launches; the RX, which is our flagship 32-bit microcontroller, and our RL, which is our flagship 16-bit, low-power microcontroller. Just recently we have announced our RX200 line, which is 32-bit processing power with a very lowpower footprint. It really scales the RX family from the high-end 600series down to the low-end. It is very competitive with other suppliers here in the U.S. The other exciting thing we have introduced is the RL, which is the first product that exemplifies the merger synergy we had between

design. On the analog and power side, we had several new devices: our Super Junction MOSFETs, our Silicon Carbide Diodes and our IGBTs. We’ve made a very large push in the analog and power domain because we recognize that in today’s world, we can’t be only focused on the microcontroller. How much of an influence does the engineering department have on the future products at Renesas? When I first came to Renesas, one of the first products that I worked on had customers that were largely centered in the U.S. I had a unique experience, in my opinion, trying to feed the customer requirements back into the team in Japan and really establish a great relationship Visit



“From an industry perspective, I think the challenge for Renesas is to go from being a high-quality microcontroller and microprocessor component supplier to be more solutionoriented.” with the design team. Because of the fact that I was coming into this job with a totally hands-on technical background, I was able to take requirements and translate them down into the engineering level. That, I think, has really grown. From an engineering standpoint, we’ve done several new product proposals for microcontrollers and

Renesas’ RX62G Microcontroller analog and power parts. For every product proposal we’ve made for the U.S. region, there’s always two components: an engineering and marketing component. I have been actively involved in certain proposals that have been made in the past three to four months. I’ve also got my application engineering team heavily invested. It’s absolutely important for engineering to be involved because

at the end of the day, there are chip designers in Japan who do a great job of manufacturing highquality products, but the application engineering team is the one that gets to use those products. They see a lot of the issues and requirements that our end customers are going to see. Without that involvement, we would not have the quality and the featurerich products that we have today. Engineering plays a crucial role in specifying new products. What do you look for when you are hiring a new engineer?

Renesas’ Super Junction-MOSFET


EEWeb | Electrical Engineering Community

The first thing I look for is obviously the breadth of hands-on experience that the engineer has had in the industry. Our business tends to touch a lot of different areas, technology wise, so the range of experience is important. The next thing I look for is whether the engineer has had a system-level view of his or her design. You could have analog and power design engineers or software engineers or board design people, but the thing I look for the most is whether they have a complete

INTERVIEW understanding of the systems. They may not be experts in every part of the system, but every single engineer that is on our design team has to understand the system because that is the common goal that everyone should be marching to. Connectivity is obviously a big factor in today’s market, so knowledge of everything in the connectivity space is also very important. The last thing, broadly speaking, is the ability to generalize the problem. Could you tell us about the future of Renesas? Renesas as a company is large and it touches so many different areas of technology that I see a tremendous amount of opportunities. In this decade, we are realizing that more everyday items have some kind of processing element or intelligence written into it. It’s not just your smart meters or smart cars, it’s about your smart home or smart industry where factory automation is getting more

and more intelligent. Those are areas where Renesas really plays well into and we are well positioned to get into those domains. From an industry perspective, I think the challenge for Renesas is to go from being a high-quality microcontroller and microprocessor component supplier to be more solutionoriented. To a large extent, the semiconductor industry outside of Intel, especially in Silicon Valley and the U.S. has recognized that they need to be solution-focused. A lot of that has to do with the way the American engineering workforce is structuring their business. A lot of times, people in the engineering workforces are challenged by the number of resources they have, so they are relying more on the semiconductor company and other suppliers to provide more and more of their product solutions. The other interesting challenge for us is connectivity. Renesas has not been known as a pioneer in connectivity solutions and we see

the need to build up expertise in the communication domain. I see a lot of new products coming out in the next few years in the connectivity space. It’s an exciting thing that makes me want to come into work everyday. ■

For more information about Renesas, visit their website:



Technology You Can Trust

Avago Technologies Optocouplers

A Superior Technology for High Voltage Protection! IEC 60747-5-5 Certified

Optocouplers are the only isolation devices that meet or exceed the IEC 60747-5-5 International Safety Standard for insulation and isolation. Stringent evaluation tests show Avago’s optocouplers deliver outstanding performance on essential safety and deliver exceptional High Voltage protection for your equipment. Alternative isolation technologies such as ADI’s magnetic or TI’s capacitive isolators do not deliver anywhere near the high voltage insulation protection or noise isolation capabilities that optocouplers deliver. For more details on this subject, read our white paper at:

FEATURED PRODUCTS Stereo Audio CODEC with miniDSP The TLV320AIC3254 (sometimes referred to as the AIC3254) is a flexible, low-power, low-voltage stereo audio codec with programmable inputs and outputs, PowerTune capabilities, fully-programmable miniDSP, fixed predefined and parameterizable signal processing blocks, integrated PLL, integrated LDOs and flexible digital interfaces. The TLV320AIC3254 features two fully-programmable miniDSP cores that support applicationspecific algorithms in the record and-or the playback path of the device. The miniDSP cores are fully software controlled. For more information, please click here.

I2C No-Offset Bus Buffers NXP Semiconductors introduced the PCA9525 and PCA9605 — the industry’s first no-offset I2C-bus buffers, which enable system designers to isolate capacitance and interface with other bus buffers. These groundbreaking bus buffers use the no-offset scoreboard method to decide signal direction, rather than using a directional pin and relying on offset voltages to control direction and prevent bus latchup. Significantly, the no-offset devices are interoperable even with static offset or incremental bus buffers, allowing easy design-in regardless of which other devices are on the bus. For more information, click here.

11MHz Single Supply JFET Amplifier The OPA140, OPA2140, and OPA4140 op amp family is a series of low-power JFET input amplifiers that feature good drift and low input bias current. The rail-to-rail output swing and input range that includes V– allow designers to take advantage of the low-noise characteristics of JFET amplifiers while also interfacing to modern, single-supply, precision analog-to-digital converters (ADCs) and digital-to-analog converters (DACs). The OPA140 achieves 11MHz unity-gain bandwidth and 20V/µs slew rate while consuming only 1.8mA (typ) of quiescent current. It runs on a single 4.5 to 36V supply or dual ±2.25V to ±18V supplies. For more information, please click here.

Microcontrollers with On-Chip 40nm Flash Memory Renesas Electronics Corporation announced the RH850/F1x Series of 32-bit microcontrollers (MCUs) for automotive body applications as the first products to be released in the RH850 Family of automotive MCUs with on-chip flash memory employing the industry’s most advanced 40 nanometer (nm) process. The new MCUs are designed for use in a variety of automotive body applications and provide many advantages. The RH850/F1x Series is comprised of three groups and has a total of more than 50 products from Low-end to High-end, the RH850/F1L, RH850/F1M and RH850/F1H. For more information, please click here.




2 2 - 2 5 ,

2 0 1 2

Hyatt Regency Hyatt

Orange County, CA

Join us this Fall! Hands-on Labs, Seminars, Meet the

Experts, Demos, Partner Solutions and much more! For all things DevCon – including up-to-date course information, lodging and registration details – go to: SESSION TRACKS

Human Machine Interface Display Technologies Guest Speaker System Design Dean Kamen Motor Control Dean Kamen landed Automotive in the limelight with the Segway, but he Security has been innovating since high school, with more than 150 patents under his belt. Recent projects include portable energy and water purification for the developing world.





n li


ma S e th

m as Electronics A © 2012 Renes


Machine to Machine Computing Architectures Cloud Computing Analog & Power Hosted by the Development Tools Number One Connectivity MCU Supplier Worldwide Operating Systems

rt Society

erica Inc. *Source: Gartner 2011 Worldwide Semiconductor Market Share Database, M

Key Sponsors


arch 2012 re s


For course descriptions, visit Meet the Experts Design Issues for Systems That Use LCD Panels M2M Development Development Ecosystem and Services Customer Feedback Expert Panel: The Auto Industry Speaks Expert Panel: The Future of Auto Software/System Development Model-based Development

Connectivity Industrial Ethernet Instant Connectivity for the “Internet of Things” PLM-1 Modem Renesas Connecting through 802.15.4 Radio

Human Machine Interface Audio Solutions on the RX MCU Family Capacitive Touch Based User Interfaces and Hardware-based Solutions


Enhance Embedded Designs with Low-cost TFT LCD Solutions

LibUSB: Create a Solution Without the Class Struggle

Embedded Vision: Creating “Machines that See”

CAN In a Day: Using the RX CAN API

Driving E Ink Displays

IR and Bluetooth Connectivity Using the RL78 Development Tools

Direct-drive LCD Using Altia to Design a GUI and Deploy it on Renesas SH7269

Getting Started with Renesas Development Tools

Extreme Makeover with the RX600: Adding Touch/Graphics to Your Product

Cost Effective HIL for Rapid Prototyping

Introduction to e2studio, The New Eclipse-based IDE from Renesas

Direct-drive LCD Software Integration for the RX62N/RX63N

Virtual HIL test/ISO 2626 using Processor Models

Getting the most out of the Renesas Demonstration Kits (RDKs)

Incorporating a Capacitive Touch Interface into Your Design

Introduction to Velocity Lab

Trends in Embedded Software Development

Industrial Controls GUI Application Using emWin

High-performance Compiler Solutions for Renesas MCUs


Simulation: Expert Insights into Modelling Microcontrollers Automotive

Infotainment & Instrumentation Solutions QuantiPhi for RL78: The Fastest Path from Idea to Implementation Simulation: Moving Development into the Virtual World Active Safety Solutions Graphic System Design Considerations

Insights into MCU & Mixed Signal Design Automotive Quality/Failure Analysis Working with AUTOSAR Trends in Automotive Communication Improve a Product’s User Experience with Model-based UI Design Intelligent Power Devices Mastering Functional Safety and ISO 26262 Advanced SOC for Telematics and Infotainment MICON Racing – Qualify using QuantiPhi for RL78 Using Processor Models for Software Development and Validation HEV/EV Traction Motor Control Lab Computing Architecture Renesas Next-generation Microcontroller and Microprocessor Technology Roadmap

Getting the Most Out of the GNU Toolchain Getting Started with e2studio, The New Eclipse-based IDE from Renesas Introduction to the RX Arduino Using Embedded Tools for I2C, SPI, and USB Debugging and Development on the Renesas RX63N RDK Seeing Inside your Target at Run-time with µC/Probe Advanced Debugging with the RX600 Migration from HEW to Eclipse Migration from Cube Suite to Eclipse Using Software Building Blocks for Faster Time-to-market VectorCAST Tools: A Complete Test Environment for Safety-critical Applications Using a Renesas Code-generation Tool for RL78 Devices e2studio Advanced Topics Advanced Debugging on RX with IAR Embedded Workbench Security NFC Ecosystem and Solutions

Microcontroller Solutions Enabling a Greener Society

Hardware Roots of Trust – A Foundation for Security

The Core Difference: When the Core Matters

Security Solutions for the Automotive Industry

RH850 & RL78: Introducing the Next Generation of Microcontollers for Automotive Applications

Security Solutions Part 1: Javacard Applet Development Training

Benchmarking using EEMBC Optimizing Performance of RX-based Applications

Security Solutions Lab 2: Secure Host Firmware Upgrade using BoardID Secure Solution

Flat Panel Displays: LCD Technologies and Trends Flat Panel Displays: Touch Panel Technologies and Integration Flat Panel Displays: Beyond the Basics Flat Panel Displays: How to Overcome High Ambient Light Conditions Flat Panel Displays: Exploring a 2D/3D Solution Flat Panel Displays: Advanced Technology Trends M2M and Cloud Solutions Energy-efficient Communications with Wi-Fi Adding Wi-Fi to Embedded Applications Wireless Connectivity for Embedded Systems

Motor Control Power Factor Correction: Why and How? Sensorless Vector Control and Implementation: Why and How Know your Precise Position with RX600 MCUs Field-oriented Control Using a 16-bit Low-power MCU Operating Systems Using ThreadX and IAR Embedded Workbench on the RX Processor Introduction to RoweBots’ Ultra Tiny Linux™ RTOS Embedding USB: Implementation Challenges and Limitations FreeRTOS Lecture Rapid Development on the Renesas RX63N RDK using µEZ® and FreeRTOS Introduction to Python Software Development with an Open Source Real-time Operating System HTML5 HMI Development with QNX Developing Next-gen Automotive User Interface using EB GUIDE 5.3 w/Windows Embedded Automotive 7 and Renesas R-Car H1 Getting Started with Micriµm’s µC/OS-III Kernel Embedding TCP/IP: Working Through uC/TCP-IP Usage Introduction to the .NET Micro Framework System Design Technologies Are all Batteries Created Equal? A/D Converter Fundamentals Designing Modern Medical Systems Digital Filtering on a MCU Infinite Runtime: Energy Harvesting with Renesas MCUs Moving from 8-bit to 32-bit MCUs

M2M: How to Create Revenuegenerating Services and Applications

Battery Management

Wireless Sensors Wireless Transceivers M2M: Cloud Connectivity with RX and Exosite

Exploring the Safety Features of the RX210


ADC Resolution: Myth and Reality

Low-power Design Increase the Dynamic Range and Precision of Digital Filters Using a FPU

IGBT vs. Mosfet: Which Device to Select?

RL78 Project Configuration Tips

How to Make Your House Smarter

Sensor Fundamentals

Digital Power: Design and Architectural Trade-offs

Extreme Low-power Design: Tools, Design Techniques and Implementation

Increasing the Performance of PFC and LED Driver IC Applications Optical Isolation, SSR Switching, and Ambient Light Sensing in MCU-based Applications IGBTs for HEV/EV

Register Today! Limited Space Available.

RX Project Configuration Tips

Creating Virtual EEPROM on Renesas MCUs Implementing Bootloaders on Renesas MCUs Designing Energy Harvesting Applications with the RL78 Portable Instrumentation Applications with the RL78 Embedded Systems Bootcamp


The High Resistanc

Part 1 Can

Your Jonathan Tucker

Senior Marketer And Product Manager Tektronix/Keithley Instruments


EEWeb | Electrical Engineering Community


hs and Lows of ce Measurements:

You Trust r Test? All too often, scientists and engineers tend to take the process of measuring resistance for granted. All it takes is attaching test leads to a digital multimeter (DMM), setting its function to Resistance, and making the measurement, right? Although that might be true for most resistance measurements, characterizing resistances lower than 10 ohms or higher than mega-ohms is often significantly more complex.




Figure 1: Ohm’s experimental setup (© 1999 IEEE. Reprinted, with permission, from Joseph F. Keithley, The Story of Electrical and Magnetic Measurements: From 500 BC to the 1940s, IEEE Press, 1999.)

To appreciate why it’s important not to take resistance measurements for granted, let’s take a moment to look back at what physicist and mathematician Georg Simon Ohm went through to understand the relationship between the length of a wire and electromagnetic force in his “hydroelectric circuit” experiment to establish Ohm’s Law.

Ohm suspended a magnetized needle over conductor C. Ohm relied on one of Coulomb’s earlier examples of torsion balances in his approach. It hung on a ribbon torsion element with a knob on top, graduated in 100 parts. Ohm assumed correctly that the strength of the magnetic field surrounding the conductor was directly proportional to the current flowing through the wire.

In 1825, Ohm published a paper titled “Vorlaufige Anziege des Gesetzes, nach welchem Metalle die Contractelectricitat leiten” or “Preliminary Announcement of the Laws, According to which Metals Conduct Contact Electricity.” The object of his experiment was to determine the relationship between the decrease in the electromagnetic force surrounding a current-carrying wire and the length of the wire. His experiment involved the addition of longer and longer wires to the circuit. Although Ohm’s original paper included no illustrations, Figure 1 depicts the experimental setup he described.

A single chemical cell with a zinc and a copper electrode in a trough 13 inches high and 16 inches long provided the electromotive force needed. The electrolyte was dilute sulfuric acid (Ref. 1).

Wires A, B, and C, the “invariable conductors,” were 0.104 inches thick and totaled four feet in length. The “variable conductors” completed the circuit. In order to measure the conductors one at a time, one end of the conductor was placed in cup N and the other end in cup O. To measure the magnetic force of the current,


Figure 2: Single-walled carbon nanotube (CNT)

EEWeb | Electrical Engineering Community

Ohm’s experimental setup is primitive in comparison with the technology available today to measure resistances, and he was likely unaware of many of the sources of measurement error that can affect the integrity of today’s low-level resistance measurements. Back then, the major sources of measurement error with which Ohm concerned himself were related to the quality of his wires and their metallurgy. Small impurities in the copper wiring used, for example, later proved to decrease their conductivity substantially. Today, it’s important to be conscious of potential sources of error such as thermoelectric EMFs and drift, contact resistance, device heating, lead resistances, and leakages. These sources of error are particularly significant at both the bottom and top ends of the resistance testing envelope. For measuring resistances of less than an ohm, the most widely used technique is to source a current and measure the resulting voltage. The two-wire method shown in Figure 3 is often used to measure resistance. The test current is forced through the test leads and the resistance ® being measured. The meter then measures the voltage across the resistance


through the same set of test leads and computes the resistance value accordingly. However, for low resistance measurements, the twowire method presents some problems because the total lead resistance (RLEAD) is added to the measurement. Given that the test current (I) causes a small but significant voltage drop across the lead resistances, the voltage (VM) measured by the instrument won’t be exactly the same as the voltage (VR) directly across the test resistance ®, which can result in considerable error. Typical lead resistances range from one milli-ohm to 1-2 ohms. When attempting to measure resistances lower than these values, the resistance of interest will be completely swamped by the lead resistance. Lead resistance will, in fact, be the dominant source of error. Even when the resistance under test falls into the 10 to 100 ohms range, a two-wire measurement can still produce an inaccurate reading, depending on the level of lead resistance involved. Because of the limitations of the two-wire method, the four-wire (Kelvin) connection method shown in Figure 4 is generally preferred for low resistance measurements. A DMM, micro-ohmmeter, or a separate current source and voltmeter can be used for these measurements.





Test Current (I)



Lead Resistances



Resistance Under Test


VM = Voltage measured by meter VR = Voltage across resistor Measured Resistance =

VM = R + (2 x RLEAD) I

Figure 3: Two-wire resistance measurement model




With this configuration, the test current (I) is forced through the test resistance ® through one set of test leads, while the voltage (VM) across the DUT is measured through a second set of leads called sense leads. Although some small current may flow through the sense leads, it is usually negligible and can generally be ignored. The voltage drop across the sense leads is negligible, so the voltage measured by the meter (VM) is essentially the same as the voltage (VR) across the resistance ®. Consequently, the resistance value can be determined much more accurately than with the two-wire method. The voltage-sensing leads should be connected as close to the resistor under test as possible to avoid including the resistance of the test leads in the measurement.

DMM or Micro-ohmmeter Source HI

Sense HI



VM Sense LO

Source LO

In the next part of this series, I will illustrate the differences and the test results achieved when making a two-wire and four-wire resistance measurement on a printed electronic circuit board that used electronic ink. ■

Test Current (I)


Lead Resistances



Resistance Under Test


VM = Voltage measured by meter VR = Voltage across resistor (R) Because sense current is negligible, VM = VR Measured Resistance =


Figure 4: Four-wire resistance measurement model


EEWeb | Electrical Engineering Community


Get the Datasheet and Order Samples

1.2A High Efficiency Buck-Boost Regulators ISL9110, ISL9112


The ISL9110 and ISL9112 are highly-integrated Buck-Boost switching regulators that accept input voltages either above or below the regulated output voltage. Unlike other Buck-Boost regulators, these regulators automatically transition between operating modes without significant output disturbance.

• Accepts Input Voltages Above or Below Regulated Output Voltage

Both parts are capable of delivering up to 1.2A output current, and provide excellent efficiency due to their fully synchronous 4-switch architecture. No-load quiescent current of only 35µA also optimizes efficiency under light-load conditions. Forced PWM and/or synchronization to an external clock may also be selected for noise sensitive applications. The ISL9110 is designed for standalone applications and supports 3.3V and 5V fixed output voltages or variable output voltages with an external resistor divider. Output voltages as low as 1V, or as high as 5.2V are supported using an external resistor divider. The ISL9112 supports a broader set of programmable features that may be accessed via an I2C bus interface. With a programmable output voltage range of 1.9V to 5V, the ISL9112 is ideal for applications requiring dynamically changing supply voltages. A programmable slew rate can be selected to provide smooth transitions between output voltage settings. The ISL9110 and ISL9112 require only a single inductor and very few external components. Power supply solution size is minimized by a tiny 3mmx3mm package and a 2.5MHz switching frequency, which further reduces the size of external components.

• Automatic and Seamless Transitions Between Buck and Boost Modes • Input Voltage Range: 1.8V to 5.5V • Output Current: Up to 1.2A • High Efficiency: Up to 95% • 35µA Quiescent Current Maximizes Light-load Efficiency • 2.5MHz Switching Frequency Minimizes External Component Size • Selectable Forced-PWM Mode and External Synchronization • I2C Interface (ISL9112) • Fully Protected for Overcurrent, Over-temperature and Undervoltage • Small 3mmx3mm TDFN Package

Applications • Regulated 3.3V from a Single Li-Ion Battery • Smart Phones and Tablet Computers • Handheld Devices • Point-of-Load Regulators

Related Literature • See AN1648 “ISL9110IRTNEVAL1Z, ISL9110IRT7EVAL1Z, ISL9110IRTAEVAL1Z Evaluation Board User Guide” • See AN1647 “ISL9112IRTNEVAL1Z, ISL9112IRT7EVAL1Z EvaluationBoard User Guide”






2 LX2 VOUT 1

FB 12

L1 2.2µH V OUT = 3.3V/1A C2 10µF


6 10 9 8 7





C1 10µF



90 VIN = 5V 85 80

VIN = 3V

VIN = 2.5V

75 VOUT = 3.3V 70 0.01


V IN = 1.8V TO 5.5V






July 13, 2012 FN7649.2


Intersil (and design) is a registered trademark of Intersil Americas Inc. Copyright Intersil Americas Inc. 2011, 2012 All Rights Reserved. All other trademarks mentioned are the property of their respective owners.



C eb om .c m om un ity

W eb Ele ct ric al En w gi w ne w er .e in ew g

EE Making Wireless Truly Wireless: Need For Universal Wireless Power Solution

Dave Baarman Director Of Advanced Technologies

"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium laudantium,

doloremque totam



eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae


dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil





Automotive, Medical, Telecom, POS LCD for Any Application

Microtips Technology QVGA Green w/LED Backlight 7” High Bright

From design to service, Microtips offers a variety of competitively priced Liquid Crystal Display modules which includes standard character and graphic monochrome, passive and active color displays with white LED as well as custom LCD modules and complete OEM services. For your own design needs please contact

Microtips Technology:

240 x 160 COG w/LED Backlight 1.888.499.8477

Little Sensors, Big Ideas®


Lose all the wires, keep all the data MicroStrain’s new LXRS™ Wireless Sensing System offers 100% data throughput under most operating conditions With Lossless Protocol

Without Lossless Protocol

Our new LXRS™ Wireless Sensing System includes:

• Lossless wireless communications protocols provide 100% packet success rate • Extended range radio link to 2 km • Scalable wireless sensor networks support continuous, burst, and hybrid sampling modes • Time synchronized to +/- 32 microseconds

Call 800.449.3878 or visit us online at

To learn more about our LXRS Wireless Sensor Networks, scan here for demo video


What’s in

---------------------------------library ieee; use ieee.std_logic_1164.all; entity AND_GATE is port( A: in std_logic; B: in std_logic; F1: out std_logic ); end AND_GATE; architecture behv of AND_GATE is begin process(A,B) begin


EEWeb | Electrical Engineering Community


a Name?


Dave Vandenbout XESS Corp. - Founder

When you’re writing your HDL code, what consideration should be top-of-mind?

Creating a good hierarchy?

Maintaining a synchronous design?

Registering inputs and outputs?

I’ll suggest a more basic concern:

finding good names for stuff.




Think for a moment what your HDL coding life would look like if you took the time to clearly name the various I/Os, signals, registers, modules, etc. • You would write better documentation. The HDL code itself would help to tell the story about how the design does what it is meant to do. This means the surrounding comments can concentrate on telling why the design is built this way. • You would documentation.




Because the HDL names assist with the documentation, fewer actual comments are needed. And these comments have to be updated less frequently as the design changes because the “why” of a design changes less frequently than “how” it actually operates. • You would introduce fewer bugs. Bugs get into the code because we place them there, usually because we’re confused about what the design is doing. Good names carry along the meaning of the problem the design is meant to solve, so it’s easier to load the problem into your head. Then you’ll spend less mental energy translating the variables back into the problem domain and more on producing correct code. • Your debugging sessions would be easier. For the same reason, it’s easier to trace and find errors when the debugger shows variables whose names refer directly to items in the problem domain. • Your designs would be re-used more often. If a design is easier for you to understand and modify, the same will apply to others and they’ll be more likely to use it as well.

altitude of a rocket. Not so for a variable named h or (even worse) x. • A variable should refer to the problem domain, not the implementation. For example, naming a variable heightCounter implies that the rocket’s altitude is maintained within a counter. This speaks to how the altitude is computed within the circuit, but that may change as the design’s implementation changes. You don’t want to have to change your variable names if your logic changes or – worse yet – have your names give misleading information about how the design works. • Variable names should be between 10 and 16 characters. This makes the variables easiest to comprehend while still conveying meaning (although you can stretch this to 8-20 chars with only slightly worse results). Of course, variable names that describe the problem domain can get rather long (heightOfAscent is already at 14 characters), so you’ll have to employ some techniques to shorten them like removing nonleading vowels (hghtOfAscnt) and removing articles (hghtAscnt). • The greater the scope of the variable, the more descriptive the name should be. For example, you can use i as the index in a short generate loop but not for a 1000-line block of code (well, nothing would be appropriate for that). In addition to the general principles shown above, I also have conventions for how I adorn names in my VHDL code. I use capitalization and append suffixes to make it easier and faster for me to generate meaningful, consistent names. It also indicates where the signals come from and where they can be used.

Here are the rules I use:

Here’s another indication of the importance of naming: “The Power of Variable Names” in Code Complete, is 25% longer than any other chapter. You could stop reading this right now and go read that chapter, but I’ll synopsize the germane points for you:

• Entities, architectures, procedures, functions, typenames: CamelCase with an initial uppercase letter.

• A variable name should describe what it represents.

• Component instantiations: CamelCase with an initial U.

For example, heightOfAscent would be a good name for a variable in a telemetry module that records the current

• Constants & generics: all caps with underscores and either a _C or _G as a suffix.


• Packages: CamelCase with an initial uppercase letter and ending with Pckg.

EEWeb | Electrical Engineering Community


• Signals & variables: CamelCase with an initial lowercase letter and one or more of the following suffixes:

The comments in the code show some of the places where my naming conventions help out. But there are also a couple of places where I violate my conventions:

- _i: Input port.

• I use short, nondescriptive names for the a_i and b_i inputs. In my defense, there aren’t any really good names for these since this is just a module for performing a general-purpose calculation that would be used in some larger application. I also tried to mitigate this by placing AminusB in the output names to show that the difference of these two inputs is what’s being worked with.

- _o: Output port. - _s: Signal local to architecture. - _v: Variable local to process. - _b: Active-low (complementatry) signal. - _r: Current register value. - _x: Next register value after clock edge. - _a: Asynchronous signal. - _d: Delayed version of signal. - _e: Enabled version of signal. To show how I use my conventions, here’s an artificial example of a module that integrates the difference of two signals:

• I violated the CamelCase naming format for some of the signals such as intgrlAminusB_r because the correct version, intgrlAMinusB_r, looked rather odd and was hard to read. These violations demonstrate the last and most important naming convention: don’t be a prig! These rules exist to serve you and not the other way around. If you find places where they make the code less clear, then either violate them or change the conventions to account for these new circumstances. There’s no reason for slavish adherence to some standard if it generates poor code. It can be hard to remember a new set of naming rules. To help myself, I created a bunch of macros for the Notepad++ editor which automatically generate VHDL that follows my naming conventions. While I don’t recommend my rules for everyone, you should have some convention to guide you. Maybe you can modify my macros to fit your design environment. ■



EEWeb Pulse - Issue 66  

Interview with Ranjit Deshpande - Vice President of Engineering at Renesas Electronics America; The Highs and Lows of Resistance Measurement...

EEWeb Pulse - Issue 66  

Interview with Ranjit Deshpande - Vice President of Engineering at Renesas Electronics America; The Highs and Lows of Resistance Measurement...