Embedded Developer - Total Phase by EEWeb Magazines

High-Accuracy

Neat

Software

Tools

LED Drivers

You've Never Used

Kumaran Santhanam CEO of Total Phase

Total Integration Total Phase's powerful, affordable development tools

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

CONTENTS

4 8 18 26

TECH ARTICLE

NEAT SOFTWARE TOOLS YOU’VE NEVER USED

apples a=1, p=16, p=16, l=12, e=5, s 1+16+16+12+5+19=69 hash of “apples” is 9

oranges o=15, r=18, a=1, n=14, g=7, e 15+18+1+14+7+5+19+79 hash of “oranges” is 9

TECH ARTICLE

NXP’S ACCURATE & RELIABLE LED DRIVERS

COVER INTERVIEW

INTERVIEW WITH KUMARAN SANTHANAM - CEO OF TOTAL PHASE

FEATURED PRODUCTS

Total Phase’s Beagle Protocol An

TOTAL PHASE’S BEAGLE USB PROTOCOL ANALYZERS

FEATURED ARTICLE AXP LOW POWER LOGIC DESIGN PROGRAM

EMBEDDED WORKBENCH FEATURED VIDEOS LOGICHEADS: BASICS OF LOGIC VIDEO SERIES

Total Phase’s Beagle Protocol An

17 32

••Neat Software ••Development Tools ••••You’ve Never Used ///// Mike

{

van

Lammeren, Nuvation /////

•• •

{

Software developer Michael van Lammeren reports on some innovative techniques his engineering team used for a recent project. Their approach for developing simple, robust code allowed them to meet difficult design requirements and avoid costly schedule delays.

•• •• ••

TECH ARTICLE A Nuvation software developer never knows what challenges the next electronic design services project will bring. Oscilloscopes and development kits are pretty standard tools of the trade, but a recent project had us discovering an old tool and creating some interesting new ones. At the start of the project, our team was presented with these requirements for a new embedded device:

•• •• Here is a table representation of the requirements:

•M easures, calculates and stores data in around 250 fields • Responds to network queries over: Web, Telnet, SNMP & Modbus • Uses the 150 MHz Freescale K60 with 512 MB Flash and 128 KB RAM We have been around long enough to know that a list with 250 items will require ongoing updates. We knew that we would almost certainly need to add, edit and delete fields during software development. We needed an approach that would give us the flexibility to deal with the changing requirements. We needed to start building tools! We started by converting the requirements for the 250 fields from an Excel file to a data structure in a script. We checked that script into version control (SVN in this case) to help manage all the changes. Next, we added code to the script that used the data structure to generate C code, including: struct definitions, accessor functions, and header files. With a script that turns requirements into code it is very easy, for example, to change a field from an integer to a float. You can simply change the data structure in one place, re-run the script, and check in dozens of changed files. Thanks, computer! We then decided to generate our documentation. We added generation of Doxygen-style comments to our script, and used Doxygen to generate great documentation for the development team. Our development environment picked up on those comments, and helped with tooltips and code completion. We also generated documentation deliverables for the end of the project. There is an SNMP MIB file which describes that network interface, as well as a conceptually similar Modbus Register Map. All were generated every time we reran our script.

Here are the same requirements, in the script:

The generated C struct definition looks like this:

•• •• ••

//////////

•• •• •• •

Next, we really started to get fancy. We added more and more fields to the data structure in the script, such as callbacks to validation functions for fields that hold IP addresses. We added callbacks to configuration functions, which trigger whenever certain fields are modified. A similar approach handled security for specific fields and users. Some fields are stored in RAM, others in non-volatile memory, and still others aren’t stored at all, but are actually calculated at run-time. All were covered by the script. By the end of the project, the code generation script was 2,000 lines long, and directly generated 20,000 lines of code across 23 files. Indirectly, the code also feeds into Doxygen, and a tool called Gperf (which we’ll touch on more later), to generate even more code for us. What would have been a maintenance nightmare turned into something more flexible and powerful than originally imagined. The team was free to work on the hard problems, and had the luxury of saying “no problem!” to customer change requests. Finally, by being able to look at a high-level representation of the source code, we were able to spot logic errors early in software development. After solving the problem of storing the data, we moved on to the next challenge. We needed to retrieve that data over multiple network interfaces: Web, Telnet, SNMP, and Modbus. The data lived in a large C struct with 250 members. Each member of the struct held the data for a field. For programming convenience, there were accessor functions to read and write the data. Each (automatically generated) accessor function referenced a struct member, like in the example below:

That worked great for the web application, where we hard-coded references to accessor functions to build up pages. However, we also needed to support Telnet, SNMP and Modbus. Queries on those interfaces originated from users on the network, and could read or write any combination of data fields. To make the problem more complicated, those three network interfaces have very different keys to identify the data fields. The Telnet interface uses a text key, SNMP uses Object Identifiers, or OIDs, and Modbus breaks up the 4-byte IP address field into two 2-byte words, identified by integers. The table below shows the different keys:

Since Modbus keys, called “Registers”, are sequential integers, we simply created an array to map registers to functions. We also used a helper function to convert the various data types into the 2-byte words that Modbus needed. The first parameter to the helper function is the accessor function, and the second is an offset. Our array maps Register 88 to get_modbus_register(get_ WIFI_IP_ADDRESS(), 0) and Register 89 to get_ modbus_register(get_WIFI_IP_ADDRESS(), 1). Of course, that array was another task for our codegeneration script. That left Telnet and SNMP. Clearly, two indexes were needed to return data for those network queries. Indexes are typically built in RAM, but our embedded device has only 128 kilobytes of RAM. Also, indexes require CPU cycles to find the requested data fields. Unfortunately, with our 150 MHz processor, we didn’t have many cycles to spare. A typical implementation was not going to work for this application. We needed a solution that used little or no RAM and as few CPU cycles as possible.

TECH ARTICLE A compelling feature of the MCU in this project, the Freescale K60, is that it can execute out of Flash memory. We figured that if we could move index generation from run-time to compile-time, then the index could live in Flash, saving RAM for other tasks. That was doable because all the data fields were known at compile-time. Also, we wanted to minimize CPU usage by moving index look-ups to compile-time too. How did we do it? We found a tool called Gperf that generates minimal perfect hash functions, and made it do the work for us. A hash function takes an input (usually a string), and calculates a value (usually a number), that is based on that input. Here’s an example to illustrate the hash function concept: imagine a function that replaces letters of the alphabet with a number from 1 to 26, then sums the numbers, and returns the last digit of the total. Every word passed to such a function will return a number from 0 to 9. Just to be contrary, let’s use our example function to compare apples to oranges. How can our example hash function be used to implement an index look-up? We could pass a key to the function, then use the number returned to assign that key to a bin, represented by the value from 0 to 9. We would still need to do some run-time work to find what we are looking for, but since we know which bin to search, we only need to do 10% of the work. That is definitely an improvement, but there is a way to do even better. A perfect hash function gives us a unique bin number for each word. A minimal perfect hash function, with “minimal” meaning that the highest bin number was close to the size of the index, is even better. We could use such a function to find “apple” data in bin 1, “orange” data in bin 2, and so on, without needing a million bins. This is what Gperf did for us. Given a dataset that related keys to function pointers, it built code that maps “WIFI_IP_ADDRESS” to get_WIFI_IP_ADDRESS() for our Telnet server. A second call to Gperf built code that maps “1.3.6.1.4.1.123.2.1.2.1″ to that same accessor function for our SNMP server.

apples a=1, p=16, p=16, l=12, e=5, s=19 1+16+16+12+5+19=69 hash of “apples” is 9 oranges o=15, r=18, a=1, n=14, g=7, e=5, s=19 15+18+1+14+7+5+19+79 hash of “oranges” is 9 Gperf creates minimal perfect hash functions by repeatedly twiddling two numbers and generating hashes of all the given keys. It keeps track of all the twiddled pairs that result in a perfect hash, and from that subset, chooses the pair that minimizes the size of the hash table. This sort of brute-force approach is fairly timeconsuming, but it only needs to be done once, and it doesn’t have to be done at all on our embedded device. As a bonus for this project, the fact that Gperf implements the hash tables in code means that on our K60 these tables live in Flash, and require no RAM. That gave our device the maximum RAM and CPU cycles for measuring and calculating, which is important, because it needed about 75% CPU to keep up in realtime, and all those network interfaces needed a considerable amount of RAM. It is always satisfying when something works in theory and in practice. The code generation tools we developed and used for this project meant that we were able to avoid troubleshooting delays that often come with maintaining large codebases. What client could possibly object to that? Mike van Lammeren is a Senior Software Developer Nuvation, an electronic design services firm specializing in new product development. www.nuvation.com ■

NXPâ&#x20AC;&#x2122;s LCD Drivers

Accurate, Reliable Solutions for VA Displays in Automotive, Medical and Consumer Applications

Driving electronics are used to supply the necessary signals to display information on an LCD. To do so, dedicated ICs are employed, placed as close as possible to the display or in the case of smaller displays, somewhere on a PCB or integrated directly with the LCD in one unit.

TECH ARTICLE Vertical alignment (VA) LCD displays have become very popular in automotive instrument clusters, climate controls and car radios as well as in home appliances, medical and other devices requiring a clear alpha-numeric display. VA is a display technology in which the liquid crystals naturally align vertically to the glass substrate between crossed polarizers (see Figure 1). When no voltage is applied, the liquid crystals remain perpendicular to the substrate creating a black state as light is completely blocked by the second polarizer set placed at 90 degrees to the first. When voltage is applied, the LC molecules rotate to a horizontal position allowing light to pass through and create a white display image. Another type of nematic liquid crystal, called twisted nematics (TN), is naturally twisted. Applying an electric current to these liquid crystals will untwist them to varying degrees, depending on the current’s voltages, to cause a change in the passage of light. Compared to traditional TN displays, VA displays provide a deeper black color, a much higher contrast ratio between the characters and the background, a wider viewing angle and better image quality, even at extreme temperatures. On the other hand, VA displays typically require a higher LCD supply voltage (VLCD) and a frame frequency (ffr) that needs to be two to three times higher than for standard TN cells, which require a typical frame frequency of only 64 Hz.

VA display technology is particularly well-suited for applications where the display needs to be readable in sunlight, or mounted on a black background (e.g, in instrument clusters in the car Figure 2), or located to one side of the viewer (e.g., in the center stack of a car, where it needs to be viewable at a wide angle). Two drive methods can be used for multisegment LCD alphanumeric character displays. In the static, or direct drive method, each pixel is individually wired to a driver. While this is the simplest driving method, as the number of pixels increases the wiring becomes very complex. An alternative method is called the multiplex drive method in which each segment control line can be connected to as many segments as there are “backplanes” or segment commons of the LCD glass. This method “multiplexes” each of the segment control lines so as to minimize the number of interconnects, which enhances device reliability. As an example, in a three MUX drive each segment line drives three segments. A more sophisticated IC example is the NXP PCA8538, a 1:9 MUX rate part that generates drive signals for a static or multiplexed LCD containing up to nine backplanes, 102 segments, and up to 918 elements (which can consist of up to 114 7-segment or up to 57 14-segment alphanumeric characters). In addition, up to four chips can be cascaded to drive larger displays with an internally generated or externally supplied VLCD.

Figure 1: Liquid crystal alignment in a TN cell and a VA cell

Figure 2: Conventional vs. VA technology

The LCD driver can be a big contributor to cost with a large portion of this cost originating from the package. Typically, manufacturers implement LCDs by connecting a cased LCD driver IC (SMD) with the physical display via a PCB. A newer, alternative design is called Chip-on-Glass (COG) technology in which the LCD driver mounts directly on the display glass, reducing the number of tracks and layers on the PCB, cutting board size and complexity and trimming system cost. COG does require tight production and design coordination with LCD module manufacturers and because of that NXP, the pioneers of COG LCD technology, has worked closely with leading manufacturers to simplify PCB layouts and improve the upgradeability, flexibility and reliability of their LCD displays.

NXP offers a wide portfolio of parts specifically designed to drive VA LCD displays, including new COG as well as packaged LCD drivers. The company has upgraded its existing LCD drivers with a new series of parts. The maximum value of the VLCD voltage has been increased to 9.0V in drivers with a multiplex drive mode of up to 1:8, 12V in drivers up to 1:9 and 16V in drivers with multiplex drive mode up to 1:18. The frame frequency has been designed to be programmable over a wider range, typically from 60 Hz up to 300 Hz or even up to 360 Hz for 1:18 multiplex rate drivers. Since the new parts are pin compatible with those they replace designers can easily upgrade their existing NXP LCD drivers, resulting in better performing VA displays with either no or minimal hardware and software changes.

Additional cost-saving features on NXPâ&#x20AC;&#x2122;s LCD drivers include the integration of peripheral functions such as an on-chip charge pump and an on-chip temperature sensor. With a charge pump you have the possibility to regulate the VLCD without the requirement for external additional circuitry, so VLCD can be set to the optimum value for a specific display; this may also allow designers to choose less expensive displays. With a charge pump you can also generate adequately high VLCD even in systems with otherwise only 3.3V (or less) supply. Similarly, the on-chip temperature sensor allows temperature compensation (regulated VLCD over temp) for optimum optical performance at all times.

For more information: http://www.nxp.com/products/interface_ and_connectivity/lcd_drivers/

TECH ARTICLE

By Air, by Land, or by Sea Wherever your design takes you, embedded modules from TQ-Systems can get your product to market quicker and easier.

Our Systems on Modules (SOMs) are the smallest in the industry--without compromising quality and reliability-and bring out all the processor signals to the Tyco connectors. A TQ module can reduce your development time by as much as 12 months. For the full product line or to evaluate our modules with a starter kit : www.TQ-USA.com

TQ-Systems has decades of experience in developing and manufacturing System on Modules (SOMs) and complete devices for transportation in countless power and control applications. In the aerospace industry, for example, our modules are found in exterior and cabin lighting, baggage management, supplemental air conditioning systems, temperature control for food and beverages, engine controls, and more. Certifications such as aerospace standard EN 9100:2009 ensure quality and reliability for your projects. With offices to serve you in California and Massachusetts, we can provide you with sales, technical assistance, product distribution and support.

To order a Starter Kit or for more information: www.TQ-USA.com TQ-USA is the brand for a module product line represented in North America by Convergence Promotions, LLC

Technology in Quality

Launches New AXP Low-Power Logic Design Program Industry’s Lowest Power Logic: The AXP logic family from NXP is designed for highperformance, low-voltage, and low-power applications. Fully specified at the 0.8-volt supply range, the AXP is the industry’s fastest family of devices with the lowest power consumption and highest output drive. Currently available in the smallest MicroPak (leadless) packages, designers now have an excellent balance of power, speed, and packaging in standard logic.

Features • Very low dynamic power dissipation (CPD) • Tpd of 2.9 ns at Vcc of 1.8 V • Wide supply voltage range (0.7 V to 2.75 V) • Fully specified at 0.8 V • Schmitt-trigger action on all inputs • 4.5 mA balanced output drive • Over-voltage tolerant I/Os • Fully specified (-40 to +85 °C) • Pb-free, RoHS compliant and Dark Green

Configurable logic devices in the AXP family can perform different logic functions, thereby reducing bill-of-material part count, cost and qualification effort, as well as enabling a smaller package footprint, which is vital in portable devices. Ideally suited for leadingedge portable devices such as smart-phones, tablets, digital cameras, and portable medical devices where longer battery life is critical, the family minimizes system power dissipation and conserves battery life. Clifford Lloyd, business development director for NXP Semiconductors’ Logic Business Line, says “Using an AXP device, engineers can avoid having to make tradeoffs between power consumption and speed. AXP logic devices now offer the market a no-compromise solution with their unique combination of low power and high speed.”

FEATURED ARTICLE New Engineering Program:

The 2014 Logic Design Contest To mark the roll-out of their newest lowpower logic family, NXP is sponsoring a logic design contest based on the AXP1G5. Open to engineers worldwide and featuring the AXP1G57, the contest is designed to showcase the AXP in high-performance, low-voltage, and low-power applications. Contestants will be able to design solutions based on a free AXP1G57GM Evaluation Board provided by NXP. The evaluation board features four configurable logic devices, and allows the contestant to configure each of the devices into seven unique functions. Produced by Convergence Promotions, Embedded Developer, EEWeb, and Aspen Labs, the contestants in the AXP Logic Design Contest will provide essays, schematics and reference designs with their final submissions as they vie for thousands of dollars in prizes between January and May 31, 2014.

AXP Design Contest Information: www.eeweb.com/nxp-contest Product information: www.nxp.com/logic/AXP NXP Logic solutions: www.nxp.com/logic NXP Logic Tech zone: http://www.nxp.com/techzones/logic LogicHeads Video Library http://embeddeddeveloper.com/logicheads/

2014 AXP Design Contest 13

2014 AXP Design Contest Hereâ&#x20AC;&#x2122;s how it works: We'll send you this free development board and you design a circuit or application that uses AXP Logic. Come up with your most creative solution, send it us, and we'll judge the submissions and pick the best. Plus, everyone who enters will receive a prize for participating from NXP!

A Winning Combination: NXP Low Powe

Get a FREE logic board, show us your creative side, and WIN cool prizes.

Here's How

to Enter The contest goes live December 16th, 2013. Mark your calendar, and check out the website for more information.

1 Grand Prize Winner â&#x20AC;˘ 1 First Place Winner 1 Second Place Winner â&#x20AC;˘ 1 Third Place Winner

er Logic and Your High Power Creativity.

INDUSTRIAL

AEROSPACE

SYSTEM ON A CHIP

MEDICAL

AVIATION

CONSUMER

THREADX: WHEN IT

REALLY COUNTS When Your Company’s Success, And Your Job, Are On The Line You Can Count On Express Logic’s ThreadX® RTOS

Express Logic has completed 14 years of successful business operation, T H R E and our flagship product, ThreadX, has been used in over 1 billion electronic devices and systems, ranging from printers to smartphones, from single-chip SoCs to multiprocessors. Time and time again, when leading manufacturers put their company on the line, when their engineering team chooses an RTOS for their next critical product, they choose ThreadX. Our ThreadX RTOS is rock-solid, thoroughly field-proven, and represents not only the safe choice, but the most cost-effective choice when your company’s product

simply must succeed. Its royalty-free licensing model helps keep your BOM low, A D and its proven dependability helps keep your support costs down as well. ThreadX repeatedly tops the time-to-market results reported by embedded developers like you. All the while, Express Logic is there to assist you with enhancements, training, and responsive telephone support. Join leading organizations like HP, Apple, Marvell, Philips, NASA, and many more who have chosen ThreadX for use in over 1 billion of their products – because their products are too important to rely on anything but the best. Rely on ThreadX, when it really counts!

Contact Express Logic to fi nd out more about our ThreadX RTOS, FileX® fi le system, NetX™ Dual IPv4/IPv6 TCP/IP stack, USBX™ USB Host/Device/OTG stack, and PegX™ graphics toolkit for embedded GUI development. Also ask about our TraceX® real-time event trace and analysis tool, and StackX™, our stack size analysis tool that makestool stack overflows a thing of the patent-pending stack size analysis that makes stack overfl ows a past. And if you’re developing safety-critical products for aviation, industrial or medical applications, ask about our new Certification Pack™ for ThreadX.

Newnes

Second Editio

E REAL-TIM ED EMBEDD ADING RE MULTITH

adX for ARM, Coldfire, With Thre ices with append ctures Now archite PowerPC MIPS and

For a free evaluation copy, visit www.rtos.com • 1-888-THREADX L. Lam Edward Copyright © 2012, Express Logic, Inc. ThreadX, StackX,and andCertification CertificationPack Packare aretrademarks trademarksofofExpress ExpressLogic, Logic,Inc. Inc. ThreadX,FileX, FileX,and andTraceX TraceXare areregistered registeredtrademarks, trademarks,and andNetX, NetX,USBX, USBX,PrismX, PegX, StackX, All other trademarks are the property of their respective owners.

M CD-RO INCLU DED

EMBEDDED WORKBENCH Demo Kit for RL78/G13 The Renesas Demonstration Kit (RDK) for RL78G13 is an evaluation and demonstration tool for Renesas RL78G13 microcontrollers. The goal is to provide the user with a powerful debug and demonstration platform targeted at common applications. To aid in the evaluation of the RL78 family of microcontrollers, we include IAR´s Embedded Workbench Kickstart Edition for the RL78. This full featured toolsuite allows forup to 16KB of application code to be implemented on the RL78G13 RDK. To facilitate programming the RDK, the IAR tools support the Renesas TK Debugger which is on-board the RL78G13 RDK. Kit Contents • 32MHz RL78G13 MCU board with integrated debugger and huge peripheral set including matrix LCD, IR transmit and receive, FET, and isolated Triac. • USB Debugger Cable

ST7 REva Starter Kit The REva starter kits from Raisonance are cost effective and complete solutions to evaluate and start application development with ST microcontrollers. The starter kit package includes: • REva motherboard: universal evaluation board designed to easily and quickly evaluate a range of ST microcontrollers. The motherboard provides a host of evaluation features including LED, push buttons, switches, temperature sensor, potentiometer and interfaces for I2C, SPI and UART. • REva daughter boards: dedicated boards that contain all the specific components for a given microcontroller, including the MCU itself, a clock selector and other device dependant features.

C200 Piccolo LaunchPad The C2000 Piccolo LaunchPad is an inexpensive evaluation platform designed to help you leap right into the world of real-time control programming on the C2000 Piccolo microcontrollers. The LaunchPad is based on the Piccolo TMS320F28027 with unique features such as 64KB of on board flash, 8 PWM channels, eCAP, 12bit ADC, I2C, SPI, UART, and much more. It includes many board hardware features such as an integrated isolated XDS100 JTAG emulator for easy programming and debugging, 40 PCB pins for easy access to the pins of the F28027 processor, reset button and programmable button, etc. Not only does the C2000 LaunchPad have the required hardware for development, it is also provides users with access to example code, libraries, drivers, and many more resources through controlSUITE which is available for free. Along with controlSUITE, users can also download an unrestricted version of Code Composer Studio integrated development environment (IDE) version 5.

Total Integration 18

COVER INTERVIEW

Kumaran Santhanam CEO of Total Phase

Total Phase is a leading provider of embedded systems development tools. The company primarily makes powerful and affordable USB, I2C, SPI, and CAN development tools that feature Windows, Linux, and Mac OS X support. Founded in 2001 by current CEO Kumaran Santhanam, Total Phase began as a consulting services company, but slowly evolved into a product company after noticing common trends in the needs of its customers. A year later, the Total Phase team released its first version of its Aardvark host adapter product, making the full transition to a product company shortly after that. In the proceeding years, Total Phase went on to release a strong array of productsâ&#x20AC;&#x201D;from host adapters and software, to protocol analyzers. Embedded Developer spoke with Santhanam, about how customer feedback led to the development of the company's products, how the company will integrate the USB 3.0 protocol in the near future, and the specific problems that Total Phase helps its customers overcome.

“One of our core philosophies has been to serve developers─ being embedded people ourselves─and be able to provide a tool that is both very capable and yet at the right price point.”

Can you tell us about your current products and services that are available for embedded developers? We actually have a whole line of host adapters, protocol analyzers and software that support most of the major serial protocols used in embedded systems: USB, I2C, SPI, and CAN. The combination of all of our products helps embedded developers debug their various protocol-related problems. The host adapters are tools that allow communication with the bus. For example, our Aardvark I2C/ SPI and Cheetah SPI Host Adapter allow developers to inject their own data onto those buses. We also have a set of protocol analyzers that are purely passive. Sometimes, people have issues where they have multiple chips communicating with one another but they don’t know what is happening on that bus. They can use our protocol analyzer to get more visibility into the bus by seeing and searching through the data in real-time. We have a whole bunch of software that works with our tools to provide the visibility that people need into their systems.

On the service side of our company, all of these things are backed by engineering support that allows customers to get real answers to their questions. We really take the time to understand the customer’s issues and eventually provide them with real solutions as users of our products. Very often, if things get escalated, they get one of the engineers that worked on that product so they can get a “from the horse’s mouth” type of answer.

What types of specific problems are you trying to solve for your customers? There is a fundamental difference between writing software on a PC and writing it for an embedded system. Although it’s changing a little bit these days, this was especially true ten years ago. If you wanted to see what’s going on in your desktop software, you can fire up a debugger and see it very easily; you can write some print statements and interact with it on a console. You’ve got all the facilities in the world to do that. However, in an embedded space, very often you program a 16-pin microcontroller that has pretty much almost

COVER INTERVIEW no interface to the outside world except for a couple of blinking lights and some analog inputs. It’s a very limited environment. One of the biggest problems in an embedded environment is visibility; you really cannot tell what is actually going on in there very easily. One of the things we did which we really pioneered in this field is the concept of realtime visibility. Our tools are able to provide the user with instantaneous feedback. It is very different from a logic analyzer with triggers. You can plug our tool into your board and immediately see what is going on. Let’s say you have an embedded system with only a couple of buttons as the interface. If you push, say, the red button, it’s bad. But you don’t know why it’s bad, or why something goes wrong. What you can do when using our tool is push the red button and see underlying data on through our tool’s display on the PC. You don’t have to correlate back and set a trigger and figure out what happened. You see everything happening in real time. That’s really the key to embedded development, and that is what our philosophy is, real-time feedback and real-time visibility into what users and their applications are doing. At a higher-level, we’ve taken that philosophy throughout the entire company. For example, in our operations in shipping and fulfillment, if a customer orders before 5 PM (Eastern Time), we ship the product on the same day, and the customer can have it the next morning. It’s all about efficiency and getting that capability into people’s hands as fast as possible.

Is the job for a USB developer getting harder or easier as more companies like your own offer solutions for embedded development? There are some very complex trends in USB. The biggest trend we have seen since USB started is finding that the embedded developers usually receive the USB technology a few years after the mainstream PC market did. There is a plus and a minus in that. The plus is that they get a technology that has been relatively debugged from a usage standpoint. The minus side is that all the first-mover silicon support types of testing companies have moved on. Everybody is concentrating on USB 3.0 right now in the high-end semiconductor

and PC market. Embedded developers are being given this amazing USB 2.0, which is 40 times faster than the USB 1.1, available in chips that cost $5. It’s pretty amazing that they are getting this technology but the port is lagging behind or moving ahead. One of our core philosophies has been to serve developers, being embedded people ourselves, and be able to provide a tool that is both very capable and yet at the right price point, so that developers who are getting these new chips that are integrating USB 2.0 have the capability and visibility that they need in order to get the job done.

How much of a challenge do you think developers would have in trying to be the first ones to put USB 3.0 in embedded products? We’re going to see a lot of that with the USB 3.0 as it starts making its way into the embedded environment. It’s going to be very similar to the USB 2.0 transition when they took a little bit of work for embedded developers to understand how to use it. There are many challenges from the hardware design standpoint. USB 2.0 has a signaling rate of 480 Mbits/s and USB 3.0 is 5 Gbits/s and up. Designing board layouts has become

“Our tools are able to provide the user with instantaneous feedback. It is very different from a logic analyzer with triggers.”

nontrivial now. It is only now that USB 2.0 has started to make in rows into embedded because people are starting to figure out how to integrate that, and as soon as they get the board working, they need a way to actually see the data, which is notoriously hard to view using a oscilloscope. Which brings me back to stressing the importance of having an analyzer for debugging. The signal integrity is paramount. It’s one of the reasons why so few companies have USB 3.0 analyzers. It’s very difficult to tap those signals and make sure you are not introducing any errors. We call these errors Heisenbugs. We don’t want to introduce any Heisenbugs into the system.

You also have products for I2C, SPI and CAN Bus Protocols. Which one of these is the most popular among your customers? Well, I would say it’s a tie between I2C and SPI. Those have been around for quite a long time now, and they are still being put into new designs. I2C and SPI have different

“We really take the time to understand the customer’s issues and eventually provide them with real solutions as users of our products.”

purposes. I2C really isn’t meant for highspeed communication, but it is a great control protocol because it is a multidrop bus. You just drop a few chips in there, put them on the bus and you’re good to go. There are some challenge with that, however, because it is a protocol; it’s not just bit banging. If you get it wrong, or if you don’t send the right data, it gets difficult to perform debugging quickly. That is why our I2C products are still quite popular and growing. The SPI is on the different side of things. It’s starting to move up in the frequency range. We are seeing requests north of 50 MHz. We’ve always been cognitive of that and trying to address those needs in the market. We were one of the first to release a 50-MHz SPI adapter,

COVER INTERVIEW which allowed the user to do gapless shifting, so they can actually shift all of their data without any gaps in real time. Now we’re getting requests more for the 100-MHz range. I’m seeing a big resurgence in SPIs as they are looking to replace parallel flash chips.

Which one of the three interfaces previously mentioned is the most challenging for development? I believe they are all challenging in a different way. They do share the challenge of being Serial Protocols, and they become immediately difficult to decode on a scope or a logic analyzer. Even with the various packages vendors sell for those like decoding packages, they are all post-processing. It’s hard to get that real-time feel with Serial Protocols once you have a dedicated instrument. Generally, the three interfaces have the same challenge there, but they have different challenges as well. The I2C challenge is that, it has to comply with the I2C standard. Since all of the chips share a bus, if you do not comply with the standards, then you will encounter strange errors. Being able to see what’s going on is very important.

really don’t require any exotic electrical interfaces. One thing that is important to know is that our company has always been driven by customer feedback. Some of the really good features we have in our products are things that customers have asked for. As we accumulate these different requests and popularity of new and old protocols, we put all of them in the roadmap. We’ve got a lot of exciting new things coming down the pipe in 2014.

What advice can you give to new engineers that are just getting into embedded development? To provide some context for that, the person who is becoming an embedded engineer today sometimes doesn’t even realize that he is one. For example, mobile phone developers write applications on a very abstracted interface, which ultimately runs on an embedded system. There are a lot of people being brought into the fold, so to speak. But with regards to people who are closer to the metal and at the lower level, my biggest advice to them is to spend time to understand

SPI has a different challenge. As it is starting to reach very high-speed, it is becoming a primary memory bus, which is a real innovation in the market, wherein they are going to take all these NAND chips that probably have thirty lines to communicate with the SPI, and reducing them down to just six, independent of the size of the chips. So it’s very exciting to think about what comes with it, all of the board layouts and signal integrity issues. CAN is kind of different. It has a specific electrical requirement and can go up to 24 Volts. It has its framing and timing requirements, so it’s a whole lot different. But what’s very exciting is that we’re starting to see more of CAN in the embedded space due to the level of integration where you can buy a sub-$10 chip that has integrated CAN controllers.

Aside from the three protocols we just talked about, are there other protocols you are starting to work with?

Total Phase’s Beagle Protocol Analyzer

Yes, we have a few things on the roadmap. There are other protocols in the space that

“We make sure that in our designs we have elegance, operational efficiency, and deliverance of what is needed and not extraneous things that serve to distract and make things difficult.” the workings of the device. As these devices get more and more complicated, there will be more abstraction layers and lots of tools and software development chips that make it easier to write codes for and embedded system without really understanding what the system is doing. But ultimately, sooner or later you have to come to terms of the hard work. When that happens, if you don’t have the transparency and visibility into what you are doing, then making the product work the way you expect can be extremely challenging.

What’s the culture like at Total Phase? Our culture is similar to a typical Silicon Valley engineering culture. We have a culture of innovation, engineering and product design. About half of our employees are engineers, including the management. I would say that Total Phase is engineeringfocused, not engineering-driven because we are driven by the market and the customers’ feedback. We make sure that in our designs we have elegance, operational efficiency, and deliverance of what is needed and not extraneous things that serve to distract and make things difficult. Our customers tend to buy our products because of simplicity, easy views and functionality. We like that kind of culture, putting ourselves into customers’ shoes and deliver a product that we would use.

From the standpoint of work culture, we like to really espouse work as balanced. We don’t have people working 60 hours a week. Obviously if there are deadlines, people put in the time because they have a sense of ownership but typically, people do have time to spend with their families on weekends and enjoy life. We have a real philosophy that embedded systems improve lives and improve the general state of humanity. By embedding these computers into people’s day-to-day lives, we make things a lot easier and better. There are lots of good things that embedded systems can do. We really want to be one of the companies that have revolutionized embedded systems engineering and made it accessible to as many people as possible. The more people that are involved, the more we can work together to improve lives for everybody.

Where do you see your company in the next five years? I like to dream big. I don’t know about putting it in exact numbers like five years, but I would really like at least one Total Phase tool to be in every embedded engineer’s tool kit for whatever purpose he needs because it makes his development go that much faster, much easier and helps him produce a better quality product.

Do you have anything interesting you would like to share to our audience? On of the fundamental principles in anything is “What you can’t measure, you can’t improve.” By providing that visibility to engineers’ designs, we can help them make their products better, faster, and of high quality. It’s really all about the engineers and how we can make their process and lives much easier and smoother. ■

COVER INTERVIEW

Stay on Top of Power

The new Beagle™ USB 480 Power Protocol Analyzer • Find USB bugs in real-time • Easily correlate voltage, current and power to protocol level transactions • Get the longest operating time from your battery powered embedded systems • Optimize the power profile of your embedded system and minimize power consumption

Enabling Your Competitive Edge www.totalphase.com

+1 (408) 850-6501

Beagle

USB 480

Power Protocol Analyzer

As USB devices continue to grow in number and complexity, developers need their monitoring and analysis tools to keep pace. The BeagleTM USB 480 Power Protocol Analyzer enables your competitive edge with its unique, powerful features and a price that is a fraction of competing equipment. The Beagle USB 480 Power Protocol Analyzer Series enables VBUS current and voltage measurement within our industry-leading Data Center software. The enhanced USB 2.0 advanced triggering, extralarge hardware buffer, and one-click correlation of voltage and current measurement to protocol-level activity ensures that engineers can take advantage of our unique real-time data analysis and display, enabling them to easily debug the functionality of their embedded systems while also optimizing the power profile of their applications.

Link VBUS Current/Voltage Measurements with USB Data Other than DMMs and oscilloscopes, few tools are dedicated to measuring current and voltage of USB VBUS and even fewer link these measurements with captured USB data. The Beagle USB 480 Power Protocol Analyzer correlates current and voltage data with USB traffic at the click of a mouse button.

PRODUCT HIGHLIGHT

Create USB 2.0 Advanced Triggers and Filters Build flexible state-based event triggers with up to eight independent states and six matches per state for USB 2.0 captures. Developers can now trigger the capture, filter data, or set external triggers by matching data patterns, packet types, error types, events, and other criteria.

Host-Side Use Case

Device-Side Use Case

Developers of hostrelated products such as rechargeable batteries, tablets, and laptops can verify their VBUS current/ voltage output, and monitor any effects caused by the attachment of various peripheral devices.

There is a plethora of USB peripherals on the market, each with its own specific power consumption profile. Developers of peripherals such as web cameras, HID devices, mobile devices, and portable mass storage devices can verify how much current and voltage their devices consume, with respect to timing and USB data.

Beagle

USB 5000 SuperSpeed Protocol Analyzer The Beagleâ&#x201E;˘ USB 5000 SuperSpeed Protocol Analyzer is a world-class USB 3.0 bus monitor that provides real-time interactive capture and analysis of USB 3.0 and USB 2.0 (up to 5 Gbps). Free Data Center Software and crossplatform support for Windows, Linux, and Mac OS X make the Beagle USB 5000 v2 analyzer Ultimate a user-friendly and versatile tool for any engineer working with USB 3.0 or USB 2.0.

"A userfriendly and versatile tool."

PRODUCT HIGHLIGHT

I2C, SPI, and CAN Tools Also Available Aardvark I2C/SPI Host Adapter The Aardvark I2C/SPI Host Adapter is a fast and powerful I2C bus and SPI bus host adapter through USB. It allows a developer to interface a Windows, Linux, or Mac OS X PC via USB to a downstream embedded system environment and transfer serial messages using the I2C and SPI protocols.

Beagle I2C/SPI Protocol Analyzer The versatile Beagle™ I2C/SPI Protocol Analyzer is the ideal tool for the embedded engineer who is developing an I2C, SPI, or MDIO based product. The Beagle analyzer provides a high performance bus monitoring solution in a small, portable package. Perfect for engineers in the field and in the lab.

Cheetah SPI Host Adapter The Cheetah™ SPI Host Adapter is a high-speed SPI adapter that is capable of communicating over SPI at up to 40+ MHz. The Cheetah adapter is specifically designed to communicate with high-speed, SPI-based flash memory. It is an ideal tool to develop, debug, and program SPI-based systems.

Komodo CAN Duo Interface The Komodo™ CAN Duo Interface is a powerful two-channel USB-to-CAN adapter and analyzer. The Komodo interface is an all-in-one tool capable of active CAN data transmission as well as non-intrusive CAN bus monitoring. The portable and durable Komodo interface easily integrates into end-user systems. It provides a flexible and scalable solution for a variety of applications including automotive, military, industrial, medical, and more.

Total Phase USB Protocol Analyzers: Simplified and Streamlined Debugging Due to the widespread integration of USB into embedded applications, many developers will be faced with the challenge of working with USB for the first time. New developers need to be aware that USB is a complicated protocol. From identifying itself through the enumeration process to sending data where directed, a USB device has many functions to perform. Due to the complexity of the protocol, it can be difficult to detect and isolate problems when a USB device misbehaves. Problems can originate from a variety of layers within the USB protocol: physical, electrical, protocol, and class level. Without visibility into the USB traffic, one can waste valuable time trying to determine the nature of the failure and how to fix it properly.

PRODUCT HIGHLIGHT

Choosing the Right Debugging Tool

Faced with a wide selection of debugging tools such as logic analyzers, oscilloscopes, and protocol analyzers, finding the ideal debugging tool can be as daunting a task as fixing the bug. Thankfully, the nature of the USB protocol plays a large role in determining the ideal debugging solution. Since USB is an inherently complex protocol, debugging USB involves monitoring higher-level and protocolspecific data in larger volumes. While useful, oscilloscopes and logic analyzers capture data at a low level, leaving the captured data harder to understand and navigate. On the other hand, engineers can save hours of frustration by using a USB protocol analyzer that allows engineers to debug at a higher level and in real-time, while viewing data as packets without wasting time to decipher the bits on individual lines.

Protocol Analyzers: Hardware versus Software

USB protocol analyzers come in two basic types: software-only analyzers and hardwarebased analyzers. At first glance, software-only analyzers may seem to have an economical advantage over hardware-based analyzers. However, the advantages of hardwarebased analyzers quickly become evident when debugging embedded hosts, speed negotiation, transmission errors, or timingrelated issues. Software-only analyzers

are unable to provide visibility into these types of problems because they are entirely dependent on the host computer hardware.

Additional Considerations

Real-time display of captured data is an important feature to consider. Without realtime display, search, and filtering developers must set complicated triggers in the hopes of capturing the data of interest â&#x20AC;&#x201D; a painstaking trial and error process. The real-time analysis offered by Total Phase USB analyzers provides instantaneous feedback. Developers can see immediately if the data of interest has been captured, allowing them to quickly identify problems.

The Total Phase Solution

As a leading provider of test and measurement tools, Total Phase provides embedded engineers with powerful analyzers to decrease time-to-market and increase development efficiency. Total Phase offers a complete line of USB protocol analyzers that support up to USB 3.0, and current/voltage measurement of the USB power line. With these tools, embedded engineers can spend less time debugging and more time developing their applications. Total Phase USB analyzers would be the perfect addition to any USB developerâ&#x20AC;&#x2122;s toolbox.

EPISODE 1: IN THE BEGINNING THERE WAS LOGIC

EPISODE 2: GETTING STARTED WITH LOGIC

EPISODE 3: LOGIC FAMILIES AND SPECIFICATIONS

EPISODE 4: PACKAGING: UNDERSTANDING THE OPTIONS

EPISODE 5: HOW DO I READ A DATASHEET?

EPISODE 6: LOST IN TRANSLATION