PULSE

Micrim

EEWeb

Issue 30 January 24, 2012

EEWeb.com

Jean J. Labrosse

Electrical Engineering Community

Its all about

students hobbyists

connections. EEWeb
Electrical Engineering Community

discussions
industry experts engineers

technical documents

white papers links

Contact Us For Advertising Opportunities

reference designs

resources

advertising@eeweb.com
power

1.800.574.2791application notes

www.eeweb.com/advertising lighting

community
microcontroller wireless sensor

The user-to-user forum is for everyone, from design engineers to hobbyists, to discuss technology, products, designs and more. Join the discussions that match your interest or offer your expertise to others.

www.digikey.com/techxchange
Digi-Key is an authorized distributor for all supplier partners. New products added daily. 2011 Digi-Key Corporation, 701 Brooks Ave. South, Thief River Falls, MN 56701, USA

Join the discussion now at:

TA B L E O F C O N T E N T S
Jean J. Labrosse
MICRIM
Interview with Jean Labrosse- Founder, CEO, and President

4 13 17 18 23

TABLE OF CONTENTS

Introduction to Real-Time Kernels

BY JEAN LABROSSE
Learn about the internals of real-time kernels using a commercial-grade kernel.

Featured Products How Does Synthesis Work?

BY RAY SALEMI
An introduction to the basics of synthesis.

A System Perspective on Specifying Electronic Power Supplies: Source Characterization

BY BOB STOWE WITH TRUE POWER RESEARCH
Important source characteristics for power supply specification.

RTZ - Return to Zero Comic

27

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

JL Micrim
INTERVIEW
Jean J. Labrosse - Founder, CEO, and President

ean J. abrosse
connected to light #2, #10, #18, #26, et cetera. The outputs would be turned on in sequence giving the illusion that light was actually moving and thus chasing around. This got me interested in figuring out how strobes and chasers worked. Back then, there was no Internet and to find information I had to go to the library or my local Radio Shack, which was some 10 miles from home. I started with figuring out how to do a strobe light and eventually got into digital electronics to come up with a chaser.

FEATURED INTERVIEW

How did you get into electronics/engineering and when did you start? I was born in Montreal, Canada and I got into electronics when I was about 15 (1972). I was invited by friends to go to a concert and they had a really cool light show with

strobe lights and light chasers. A chaser is an electronic device that controls a series of lights. Each light is individually controlled. An 8-channel chaser would have 8 individual outputs. Output #1 would be connected to light #1, #9, #17, #25, et cetera. Output #2 would be

In 1980, I started a company called Mphistronique with a friend of mine (Mr. Marcel Larivire) to create disco lighting systems (discos were quite popular back then). We sold strobe lights, color organs (lights controlled by music) and our first chaser. I started with a 4-channel chaser using a couple of JK flip-flops and I was able to actually do neat things with switches and logic gates. For one thing, we could change the chase sequence.

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

INTERVIEW
Specifically, we were able to easily change the chase direction and the pattern of the chasing light. The patterns we had were 1-2-34, 1-3-2-4, 4-3-2-1 and 4-2-3-1. The rate of chasing was controlled by a ubiquitous 555 timer. Once we had our first prototype, we went to a local theatrical lighting store and offered to build these for $200 each, our cost was about $100. The store immediately ordered 10 and we were quite surprised by this initial order. We actually delivered the units a couple of weeks later and the store asked for a more complex device. So, my partner and I set out to design an 8-channel chaser. At the time, I was investigating the use of EPROMs to generate the patterns, and in fact, I believe I was the first to come up with a chaser using this technology. I designed quite a few models of chasers and the business was doing relatively well. Can you tell us about your work history/journey to becoming the Founder, CEO and President of Micrim? During my undergraduate studies (around 1980), I got interested in microprocessors and programming. Microprocessors were quite new, and at the time there were only two choices: either you used a Z80 from Zilog or a 6800 from Motorola. I actually played with both and each one had its strong points and weaknesses. I immediately fell in love with this field even though the tools were quite crude at the time. I simply could not have enough classes on microprocessors, so I decided to pursue a masters degree and take computer science classes such as high-level languages, data structures and algorithms. When I graduated, I was offered the opportunity to work for a medical electronics company in Princeton, NJ, so I sold my shares of Mephistronique to my partner. The company was called Biostim and they manufactured Transcutaneous Electrical Nerve Stimulator (T.E.N.S.) devices. These devices were used as electronic pain killers. I designed the very first microprocessor-based T.E.N.S. units on the market using an Intel 8049 and another unit using a more powerful MC68711 microcontroller unit (MCU). These were battery operated devices and the microprocessors offered us a lot of flexibility when it came to the user interface and the type of patterns we could generate out of this device. I worked for Biostim for two years, and after one year I was promoted to head of engineering and had seven people working for me. I left Biostim to pursue a dream to work in California and found a job with Allied Signal in San Diego designing engine controls for large reciprocating engines. These engines were the size of a singlecar garage and contained between six and 16 cylinders. The engines are used to pump natural gas that is extracted from the Gulf of Mexico and moved up north to supply gas to heat homes. Each engine station could have between one and 10 or so engines. Obviously a very different application than when I worked at Biostim so I had to learn quite a lot about this industry. I worked on the hardware and software design of a MC68000-based (32-bit CPU) engine control. I was responsible for the infrastructure software and a colleague was handling the control algorithms. One of the first things I put in place was a coding standard so that we could have one programming style for all the software wed create for this product. We also decided to use a real-time kernel to help us with the architecture of the system. The realtime kernel made designing the system a lot easier, and I was then convinced that I would no longer want to design products without one. I worked for Allied Signal for four years and then was offered a job in Fort Lauderdale, Florida to design much larger engine control systems. At Allied our controls were supervisory, which meant that they basically provided setpoints to other devices that controlled actuators and the like. Dynalco wanted to create full authority controls and were thus much more complex and demanding systems. And that was a direction I was interested in going. At Dynalco, I was put in charge of software engineering, and being an electrical engineer, I influenced most of the hardware designs. I was at Dynalco for a total of about 13 years. I designed many products and wrote most of the user manuals for those products. Here is a list of some of my designs: A few models of ignition control systems. Some of these controlled one or two spark plugs per cylinder. I designed a way to accurately control the firing of spark plugs with 1/16 of a degree irrespective of accelerations or decelerations. Fuel-injection control system. Dual-processor total engine control system where we

FEATURED INTERVIEW

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

INTERVIEW
controlled all aspects of the engine: ignition, speed (throttle), air/fuel ratio, starting and stopping the engine, load control, flow measurement and control, and more. In all, this control system had up to 13 different sub-systems. Both processors were running a realtime kernel and communicated with each other. Dynalco was involved in agricultural products and I also designed control systems for hay balers and windrowers. A line of MCU-based smart meters. DOS-based data monitoring and product configuration system. Im sure you know that we use the term embedded system to represent products that are typically designed around microprocessors and that have dedicated functions. Here are some examples of embedded systems: Washing machines Printers Alarm clocks Portable GPS navigation units Digital cameras Video cameras Cell phones (non-smart phones) Engine controls Basically, an embedded system has a unique dedicated function and cannot be changed. A PC is not considered an embedded system because it can run all kinds of different applications; its not dedicated to one specific thing. When I was at Dynalco, we used a real-time kernel in which we found a serious bug. After spending a year with the supplier waiting for a fix, I thought about writing my own kernel since I knew what it needed to do. So, in 1991 I set out to write a kernel I called C/OS which stands for microcontroller operating system. C/OS was mostly written in C and I wrote a paper about it to be published in a magazine. Unfortunately the paper was 70 pages long and no magazine wanted to print such an article because it would have had to be printed in parts over many three separate months (May, June, September 1992). Shortly after the first issue hit the news stand, I was approached by R&D Technical books to write a book about the kernel. I thought that 70 pages was not sufficient for a book so I added a lot more material and got it up to 250 pages or so. The book actually included the full source code for the kernel on a 3.5 floppy disk and could be used to develop products without requiring a license. Its quite possible that I actually started the open-source movement for the embedded community. I continued my part-time hobby of writing and published another book which came out in 1995: Embedded Systems Building Blocks, Complete and ready-to-use Modules in C. This book contained a number of modules that made it easy to create embedded products. The book was later translated into Korean. R&D Books sold quite a few copies of the C/OS book, and in 1998 they asked me to revise the content and create a second edition. During the six years that led to the second edition, I received a lot of feedback and requests from readers for features and additional explanations. So I decided to rewrite C/OS and create a new version of the software that I called C/OS-II. The book was also completely revised and I asked CMP Books (which acquired R&D Books) to do a hard cover instead of a soft cover book. This book now had 550 or so pages and was the first hard cover book that CMP did. C/OS-II was highly popular and was translated into Chinese and Korean. The C/ OS-II book is actually the most

FEATURED INTERVIEW

Our focus is on creating reusable software modules that are easy to use, reliable, well written, highly documented etc. to help our customer create high quality products and shave months off their schedules.
consecutive issues and months. The publisher didnt want to drag readers along for that much time. Embedded Systems Programming magazine decided to publish a reduced version of the paper in

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

INTERVIEW
popular embedded systems book ever published. I left Dynalco in 1997 and went to work for Microtec (a division of Mentor Graphics) in the consulting services group. I only stayed with Microtec for 14 months because I was always flying all over the place to visit customers and that prevented me from spending time with my family. Shortly after leaving Microtec, I was getting a large number of requests to license the use of C/OS-II in products, so I decided to start my own business Micrim. The name comes from micro and ium (which means the universe of). Micrim thus means the Universe of Micros. The C/OS-II book was the seed that got me to start Micrim, which I incorporated in 1999. What have been some of your influences that have helped you get to where you are today? I think there are five things that most influenced my career: My partner at Mephistronique who always demanded perfection and quality, and his thirst for knowledge got me to document everything I did. The C programming language which allowed code to be portable. The C coding standards we established early helped me write very clean and readable code. Using real-time kernels in products got me to appreciate the leverage that they gave me to create well-architected systems. In fact, a kernel is one of the many building blocks available to engineers today to quickly help them create products. The Internet. Do you have any tricks up your sleeve? One of the most important things I found was to establish coding conventions, document them and stick to them as much as possible when writing code. For example, I like to name things in a hierarchical fashion, such as Earth, North America, the U.S., Florida, Weston. So for software this translates to naming things based on the global picture, and then moving down to specifics. OSTaskCreate(), for example, indicates that the function is related to the operating system (OS)specifically part of task services and the exact service of creating a task. Having this convention allows API reference manuals to group related functions and services together. We apply this concept to all the modules we do at Micrim: NetARP_RxPacketFree(), FSFile_Close(), et cetera. The other thing is to try to find simple solutions to complex problems. This seems obvious, but its not always easy to do. Software should be written to be read so that others can better use what youve done. For this reason, approach projects with the understanding that you dont own the code; your employer does. Write code so you dont have to maintain it. Write code so that your replacement or colleagues will praise your work instead of saying nasty things about you once you leave. Put pride in what you do and that goes beyond just getting the product to work. Well written, clean, consistent and documented code is one of the keys to the success of Micrim. All our engineers are indoctrinated with the Micrim way, and in fact, out of the million or so lines of code we have, youd be hard pressed to know who wrote what. Another trick I have is to graphically represent concepts. I find that its a lot easier to explain something using an illustration that I narrate with text than to use code or only a textual description. If you look at my books, you will find hundreds of illustrations. One final thing: Be passionate about what you do. What has been your favorite project? I have worked on so many exciting things over the years, but my favorite project is by far writing booksmost recently, the C/ OS-III book. Writing a book like C/ OS-III allowed me to stay current with programming, processor technology, as well as find better ways to explain concepts and stay up to date with state-of-the-art technology. I have to say though that writing a book is very draining. You end up reading it four or five times over and even after its published, you always find some little things that could have been improved. However, theres no better feeling than having the first finished book in your hands. Do you have any note-worthy engineering experiences such as great accomplishments or awards?

FEATURED INTERVIEW

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

INTERVIEW
Being in the business for so long, I would have quite a few noteworthy experiences to share. Ill just mention one of them for brevity. A few years ago I hired a team of Windows developers to create a Windows-based application that would allow a PC to query a target (i.e., a product) for the current values of variables (at run-time) and display those values on virtual gauges, meters, barcharts, numeric indicators et cetera, and also allow values to be changed through virtual sliders, knobs and switches. This product is called C/Probe and can interface to any target processor, whether 8, 16, 32, 64-bit or DSP through either a J-Tag interface, RS232C, TCP/IP or even USB. You can thus develop a headless product and still be able to see what your product is doing. C/Probe actually doesnt require any target resident code when used with a J-Tag interface, so you can start looking at the values of variables as soon as you download and run code on your target. C/Probe actually won best-of-show award at Freescale Technology Forum (FTF) a couple years back. Can you tell us about the three books you wrote about embedded design, as well as some of your articles? I already mentioned the C/OS-II and Embedded Systems Building Block books. The C/OS-III book is my latest and I decided to again completely revise both the code and the contents of the book. When I did the C/OS-II book, evaluation boards were fairly expensive compared to today so I wrote the book around the 80x86 running under DOS so that most people could experience C/OS-II on their PC. With C/OS-III, I decided to create a book that would provide examples using a popular CPU architecture and offer a low-cost companion evaluation board and tools for readers to experience C/OS-III on real hardware. The book/board actually contains five parts: Part I explains what a kernel is, how to use a kernels features and also how a kernel works by explaining the inner workings of C/OS-III. Lots of details and illustrations. This part is about 700 pages. Part II describes the companion evaluation board and shows examples of how to setup and use C/OS-III with an evaluation board that we designed in collaboration with STMicroelectronics. This part is about 250 pages. The book provides a link to IARs Kickstart edition of its highly popular EWARM toolchain which contains a C compiler, assembler, linker/ locator and C-Spy debugger. The Kickstart edition of the tools allows the reader to create example applications having up to 32 Kbytes of code space. The board (called the C/ Eval-STM32F107) is based on the STMicroelectronics STM32F107 MCU which contains the highly popular Cortex-M3 ARM core. The evaluation board is also equipped with an Ethernet connector, a USB-OTG connector, an SD card socket, an RS-232C port, a temperature sensor, LEDs, a prototyping area and an on-board Segger J-Link which interface to the IAR C-Spy debugger. The award winning C/Probe, which is a data visualization tool allowing target variables to be displayed in real-time on a PC via virtual gauges, meters, bar graphs, LEDs, et cetera. The user can also change the value of variable using sliders, knobs and switches.

FEATURED INTERVIEW

A big trend in the industry is multicore. The challenge I see here is in debugging. Its already complex enough to debug single core systems. I believe the problem scales exponentially with multiple cores.
This concept was so popular that weve been able to replicate it on five additional processor architectures. We now have a C/OS-III book for

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

INTERVIEW
the following platforms: NXP LPC1768, Cortex-M3 based MCU with companion MCB1700 evaluation board and Keil tools Texas Instruments LM3S9B92, Cortex-M3 based MCU with companion EVALBOT evaluation board and IAR tools Renesas SH7216 SH2A-FPU based ultra-high performance MCU with FPU with companion YRDKSH7216 evaluation board and HEW tools Renesas RX62N RX600 based MCU with FPU with companion YRDKRX62N evaluation board and HEW tools Freescale Kinetis K50, Cortex-M4 based MCU with companion Tower system and IAR tools What are you currently working on? Unfortunately, this is something I prefer not to mention since we are in a very competitive environment. Needless to say, however, Micrim is always looking at creating high quality products to help our customers reduce time to market. How do you continue to maintain an active role in product development? I still maintain the C/OS-II and C/ OS-III code bases, I visit customers and semiconductor partners to determine their needs, I get involved in new and current product definition and requirements, features, planning and reviews, and I even test some of the software. I evaluate new technologies, I write books (we consider those as products), and I like to read technical magazines to see whats happening in the industry and adjust the direction of the company accordingly. Can you tell us more about Micrim and the technology it is developing? Micrim develops and licenses a Real-Time Operating System (RTOS). An RTOS consists of a kernel (either C/OS-II or C/OSIII), a TCP/IP stack, a File System, a USB-Device and USB-Host stacks, a Graphical User Interface (GUI) and so on. You can basically purchase any or all components individually. If you need only the kernel, you buy that. You need only a file system, you only buy that module. Our software is delivered in source code form (mostly C) and its probably the nicest looking software you can put your eyeballs on. Our focus is on creating reusable software modules that are easy to use, reliable, well written and highly documented to help our customer screate high quality products and shave months off their schedules. Its interesting to note that years ago, developers used to start their designs by selecting a microprocessor and then figuring out which tools they needed and then how to write the software. It seems that over the past few years, developers are changing their approach. More and more we are seeing developers take more of a system view and thus decide on what high-level features they need (e.g., connectivity, HMI, data storage) and then select their tools and chips to satisfy their requirements. The fact that our software is highly portable across microprocessor platforms makes this process fairly painless and natural. How has the company changed since it was launched in 1999? Well, we went from a one person company to, based on the latest UBM survey, the number one commercial RTOS supplier, so Id say quite significantly over the past 12 years. When I started Micrim, the only product I had was C/OS-II and now we have about 20 or so products. I have to say that I could not have done it alone. In 2002, a longtime friend of mine, Mr. Christian Legare joined Micrim as my partner. Together we built Micrim to what it is today. Of course, Micrims success is also attributed to the hard work and dedication of our

FEATURED INTERVIEW

We will continue to develop new products to satisfy the needs of our customers.... We will continue to improve our processes and make it even easier for our customers to use and deploy our products.

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

INTERVIEW
employees and partners. Our software is found in thousands of products worldwide and we even have products in satellites and spacecrafts. Can you tell us about some of the new technologies Micrim is working on in the medical, military, telecom or embedded design areas? Well, we develop all our products following the highest quality standards and some of them are ready to be certified for safety critical system as found in medical, avionics and industrial products. A safety critical system is one that cannot afford to fail, or else could cause damage to assets or even lives. C/OS-II has been used in countless avionics applications and the marketplace and Micrim is well positioned to assist customers with solutions: The Internet of Things, Wireless everywhere, The Smart Grid, Alternative Energy However, beyond this, Id rather not elaborate on our current and future plans. What direction do you see your business heading in the next few years? We will continue to develop new products to satisfy the needs of our customers. We expect to significantly improve our already dominant position in the marketplace since we recently added six global distributors (Arrow, Avnet, Digi-key, Future Electronics, Premier Farnell and Mouser). We will continue to improve our processes and make it even easier for our customers to use and deploy our products. What can we expect to see from Micrim in the near future? Certainly, new and innovative products as well as ways to further reduce customer product development time. What challenges do you foresee in our industry? It used to be that the software for a product could be developed by a single engineer. Now, average software development teams require between four and nine engineers, and in a lot of cases, each developer requires different specialties and skills. Managing such projects is certainly a challenge. New processors/chips are being introduced at a frantic rate and its virtually impossible to port some of our software to all the different variances. Most of the issues are not related to CPU architectures but instead with I/O devices. The fact that a lot of the semiconductor manufacturers are adopting identical CPU cores actually does little to change that problem since CPU architectures have long been isolated by high-level language compilers (mostly C and C++ for embedded systems). In other words, the instruction set and CPU architecture is generally hidden from the application developer anyway. So, even though the CPU architecture is the same from one manufacturer to another, the peripheral devices such as Ethernet, USB device, USB host, LCD controller and CAN-bus are all different, and in many cases, even different from within the same device family offered by a semiconductor manufacturer. From a software vendors point of view, it would make more sense for them to reuse as much of the same hardware IP blocks (located at the same physical address) from one device to the other so that drivers can be written once. Another challenge is the ever increasing complexity of processors and MCUs: faster, more powerful processors, high peripheral device integration, complex power, pin and clock management, user manuals having thousands of pages, multicore, mega-lines of code, debugging, code quality or lack thereof, ever rising customer expectations and time to market pressures. The list goes on and on.

FEATURED INTERVIEW

Micrium is always looking at creating high quality products to help our customers reduce time to market.
has been certified in products following DO178B Level A, countless medical products (510(k) and PMA) and industrial controls following the IEC-61508 norm. Having the DO178B Level A certification is a testament to the high quality of C/ OS-II because it had to undergo extreme testing under all possible boundary conditions. There are a lot of opportunities in

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

10

INTERVIEW
A big trend in the industry is multicore. The challenge I see here is in debugging. Its already complex enough to debug single core systems. I believe the problem scales exponentially with multiple cores. Linux has caused a big buzz in the industry mostly because it is open source and people have the perception that its free. Its a perception because everybody that has ever played with Linux will tell you that Linux is a complex system and that you will literally spend months figuring it out. So, unless you consider your time to be worth nothing then its not free. Also, because of its freeness, engineers have been embedding Linux in applications where Linux might not belong. How many times did the entertainment system (running Linux) in a plane crash? Of course, such an entertainment system is not safety critical, so apart from annoying passengers it shouldnt be life threatening. I have a TiVo unit which is obviously Linux based. Boot up time is in the order of minutes. Remote control response time is on the edge of being unacceptable. Linux is also very large and in fact, we might not see Linux in MCUs for years to come. I make the analogy of Linux being an 18-wheel truck and RTOSs are cars. You would certainly not want to drive to work every day in a huge truck, and you would not want to move furniture in a car. Each have its market and use, and engineers should be able to determine when one is better to use than the other based on their product requirements. So, some of the challenges: Satisfying customer expectations Creating drivers for ever changing peripheral devices Managing software complexity Software portability and reuse Multicore debugging Use of an RTOS or Linux when appropriate

FEATURED INTERVIEW

EEWeb
Electrical Engineering Community

Join Today
www.eeweb.com/register
EEWeb | Electrical Engineering Community Visit www.eeweb.com

11

Avago Technologies Motion Control Solutions

Worlds Smallest Miniature Reflective 3-channel Encoder

Features 3-channel encoding (AB and I) Miniature size 304 LPI Advantages Index Signal I Surface mount leadless package: 3.95 mm (L) x 3.4mm (W) x 0.95mm H) High encoding resolution Benefits No need for separate components to generate the index signal Ability to fit into miniature motor designs Various CPR capable by adjusting to the matching ROP of the codewheel Base CPR resolution can be interpolated by end user Corresponding high RPM performance with increased frequencies Catering for various user gating requirements Covering consumer, commercial and industrial applications

Avago Technologies AEDR-850x three channel reflective encoders integrate an LED light source, photo detector and interpolator circuitry. It is best suited to applications where small size and space matters! Applications include medical hand held devices, camera phones, wheel chairs, actuator, vending machine applications, just to name a few.
To request a free sample go to:

Built in Interpolator of 1x, 2x, and 4x High operating frequencies: 55 kHz at 1x interpolation Index gating -20C to 85C

1x, 2x and 4x via external pinouts Operating frequencies can be increased by external interpolator pinouts by maximum of 4x Options available for both gated and ungated versions Industrial application capable

www.avagotech.com/motioncontrol

All rights reserved.

PROJECT

Real-Time Kernels
By Jean J. Labrosse
This article describes how you can get started with learning about the internals of real-time kernels using a commercial grade kernel, running on actual hardware and using professional grade tools, all for next to nothing. What is a Real-Time Kernel? A real-time kernel is software that manages the time of a central processing unit (CPU) or micro processing unit (MPU) as efficiently as possible. Most kernels are written in C and require a small portion of code written in assembly language in order to adapt the kernel to different CPU architectures. A kernel provides many useful services to a programmer such as multitasking, interrupt management, inter-task communication and signaling, resource management, time management, memory partition management and more. Most kernels used for embedded systems are preemptive, meaning that the kernel always executes the most important task that is ready to run. Preemptive kernels are also event driven which basically means that tasks are designed to wait for events to occur in order to execute. For example, a task could wait for a packet to be received on an Ethernet controller, another task could wait for a timer to expire, yet another task can wait for a character to be received on a UART, et cetera. When the event occurs, the task executes and performs its function. If the event that the task is waiting for doesnt occur, the kernel runs other tasks. Waiting tasks consume zero CPU time. Kernels allow you to avoid polling loops which is a bad use of the CPUs time. Real-time kernels are not limited to high end 32-bit CPUs, and in fact, a kernel like Micrims C/OS-III can run comfortably on many 8 and 16-bit CPUs or even digital signal processing (DSP) chips. Many embedded programmers shy away from using a kernel because they fear that kernels add too much complexity to their application. It turns out that you only need a handful of services to get your project off the ground with a kernel. For example, with C/OS-III, you can write fairly complex multitasking application with as little as five API functions out of the nearly 70 API calls offered by C/OS-III. Years ago, embedded systems used to be designed by first selecting the microprocessor or microcontroller, then the tools (compiler, assembler, linker and debugger), and finally youd figure out how to write the software. Nowadays, many embedded systems are designed by
EEWeb | Electrical Engineering Community Visit www.eeweb.com

Introduction to

FEATURED PROJECT

13

PROJECT
starting with the software requirements and, determining what software components you can purchase off-theshelf to satisfy your needs. A real-time kernel is one such component and, is generally the first software component youll need to select because it establishes the framework upon which you can build your product. Having a kernel allows you to easily add other software components such as a TCP/IP stack, a USB stack (host or device), a file system, a graphical user interface (or GUI) and more. Some of these software components are easy to use but are quite complex to develop. For example, a TCP/IP stack can consist of well over 100,000 lines of C code, but from the applications programmers point of view, you only need to understand and use about 30 or so API functions. In other words, far easier to use than to create. The internals of the C/OS-III real-time kernel are described in a book I wrote called C/OS-III, The RealTime Kernel. There are six different versions of this book, each featuring a different CPU architecture. Each of these books is available as a free PDF download from the Micrim Web site. I personally prefer an actual book, so if you are like me, you can purchase the hardcover book either from Micrim, one of our authorized distributors or Amazon. com. C/OS-III is Source Available meaning that you can download the FULL source code for C/OS-III and use it for FREE as long as its for educational use or for peaceful research. However, you need to purchase a license (i.e., the rights to use C/OS-III) if you intend to use C/OS-III in commercial products or applications. Evaluation Boards An evaluation board is available with each book, allowing the reader to not only learn about what real-time kernels are and how they work, but also be able to perform actual experiments on actual hardware. In order to run the examples provided with each book, you will need to download the code corresponding to the book you are interested in (which depends on what CPU manufacturer or CPU architecture you prefer). The companion projects for each book are available as free downloads from the same Web page as shown above. Finally, each book requires tools to allow you to compile and download the example code. The tools that you will need depend on which book and board you get.

FEATURED PROJECT

Figure 1:

C/OS-III Task Aware screen on C/Probe.

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

14

PROJECT
Evaluation versions of tools can be downloaded for free and links to those are provided in each book. In all cases, you will have to register in order to be able to download these tools. Micrims C/Probe All of the examples provided with each book make use of a cool tool called C/Probe which is available from Micrim. Again, a free evaluation version of C/Probe can be downloaded from the same Micrim Web page as previously described. C/Probe is an award-winning Microsoft Windowsbased application that allows a user to display or change the value (at run time) of virtually any variable or memory location on a connected embedded target. The user simply populates C/Probes graphical environment with gauges, numeric indicators, tables, graphs, virtual LEDs, bar graphs, sliders, switches, push buttons, and other components, and associates each of these to a variable or memory location. With C/Probe, it is not necessary to instrument the target code in order to display or change variables at run time. In fact, there is no need to add printf() statements, hardware such as Light Emitting Diodes (LEDs), Liquid Crystal Displays (LCDs), or use any other means to get visibility inside an embedded target at run time. C/Probe obtains the values from the target either through a J-Tag interface (Segger J-Link), an RS-232C port or an Ethernet port using TCP/IP For the latter, a . TCP/IP stack such as Micrims C/TCP-IP is necessary. The free version of C/Probe allows you to display or change up to eight application variables. However, it allows you to monitor any C/OS-III variable since C/ Probe is C/OS-III Kernel Aware. Figure 1 shows an example screenshot of C/OS-III running on the Texas Instruments EVALBOT. The code for this example is provided in the corresponding book. Texas Instruments EVALBOT One of the coolest evaluation boards available with a C/ OS-III book is the Texas Instruments EVALBOT which is shown in Figure 2. The EVALBOT is a small robotic device that features a board with a Stellaris LM3S9B92 microcontroller with Ethernet, USB OTG (On-The-Go), and I2S. The kit contains wheels that are easy to attach

FEATURED PROJECT

Figure 2: Texas Instruments assembled EVALBOT

Figure 3:

EVALBOT Block Diagram

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

15

PROJECT
to the board, a display, batteries, a USB cable, and a CD with the IAR tools, the StellarisWare software, and all the necessary documentation. A block diagram of the electronics found on this board is shown in Figure 3. The EVALBOT comes as a kit where you assemble all the mechanical components with all the electronics already pre-assembled. You can purchase this kit from Texas Instruments online Web store or a TI authorized distributor. It takes about one hour to put together an EVALBOT. The examples provided in the C/OS-III book will allow you to display text onto the small OLED display, control the LEDs, the motor driving each wheel, reading bumper sensors so you can run the EVALBOT in autonomous mode and have it change its course as it hits objects. Summary

FEATURED PROJECT

A real-time kernel is an increasingly useful software component that allows you to efficiently use the resources of a microprocessor or microcontroller, and create a framework upon which you can build simple or complex applications or products. You can download any or all of six C/OS-III books in PDF format for FREE. These books describe what a real-time kernel is, what you can do with a real-time kernel and provides plenty of examples that you can actually try using on one of the companion evaluation boards. The source code for C/ OS-III is also available as a FREE download from the Micrim Web site. If you are an embedded software developer and you are new to real-time kernels, then you will find that a kernel is a useful tool to add to your toolbox.

EEWeb
Electrical Engineering Community
Contact Us For Advertising Opportunities

advertising@eeweb.com www.eeweb.com/advertising
EEWeb | Electrical Engineering Community Visit www.eeweb.com

1.800.574.2791

16

F E AT U R E D P R O D U C T S
Overvoltage Protection Controller
Linear Technology Corporation introduces the LT4363, an overvoltage protection controller that provides overvoltage and overcurrent protection to high-availability electronic systems. Supply voltages surge whenever currents flowing through long inductive power buses change abruptly. Also, automotive batteries experience a condition known as load-dump, where the voltage can stay elevated for many milliseconds. Traditional protection circuitry relies on bulky inductors, capacitors, fuses, and transient voltage suppressors. Instead, the LT4363 creates a robust, adaptable, and space-efficient design with simple control of an N-channel MOSFET. Only the controller and the MOSFET suffer the high voltage surge; downstream components can afford lower voltage ratings, thereby saving costs. For more information, please click here.

FEATURED PRODUCTS

12-port Signal Integrity Network Analyzers

LeCroy Corporation, a leading supplier of oscilloscopes, serial data test solutions and network analyzers, announces the availability of 8 and 12port models of the SPARQ series of signal integrity network analyzers. The SPARQ makes S-parameter measurements quickly and is a fraction of the price of a Vector Network Analyzer (VNA). With the 8 and 12-port SPARQ models, signal integrity engineers finally have the product they need to characterize crosstalk in multi-lane differential structures. The market is rapidly adopting high speed multi-lane serial data signaling, creating new technical challenges for design engineers. Traditional network analyzers are prohibitively expensive and time-consuming to use for 8- and 12-port S-parameter measurements. More suitable and affordable tools are needed. The new SPARQ models are priced at a fraction of the cost of less capable VNAs. For example, the 12-port SPARQ is priced similarly to a 4-port VNA. For more information, please click here.

3D NanoCompass Dev Kit

Baolab Microsystems has announced that it will have evaluation kits of its recently announced 3D NanoCompass available at the end of February 2012. This electronic 3-axis CMOS MEMS NanoCompass technology uses Baolabs patented, award winning NanoEMS technology to create nanoscale MEMS (Micro Electro Mechanical Systems) within the standard metal structure of a high volume manufactured CMOS wafer. F We are now producing NanoEMS sensors in volume in a standard CMOS production line. said Dave Doyle, Baolabs CEO. The move from lab to fab is a significant milestone for the company, proving that our innovative technology is reliable, scalable and repeatable. This was the critical stage that our customers have been waiting for. NanoEMS makes it much easier and more cost effective to integrate MEMS sensors with microcontrollers and associated electronics all on the same chip in the same CMOS production line. For more information, please click here.

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

17

How Does Synthesis Work?

Senior Verification Consultant

Ray Salemi

For the past several months weve been looking into what it takes to write good register-transfer level (RTL) code. Weve looked at how to write register-driven RTL, how to write combinatorial processes, and how to write state machines. All of this work assumes that we have a synthesis tool that converts our well-written RTL into gates. This makes the synthesis tool a critical part of our workflow. Its essential for us to understand how synthesis works, and how to make it work for us. In this article, well discuss the basics of synthesis. The first thing to know is that hardware synthesis is not software compilation. When we write software, we give little thought to how the compiler is converting our objects, data structures, types, and functions into assembly language. We just assume it will do a good enough job to let our code run on the target platform. In fact, it doesnt do us much good to think too deeply about compilation because its difficult for us to control it with our coding style.

The same is not true of synthesis. Hardware synthesis is extremely sensitive to the way we write our RTL. We can create dramatically different hardware by writing RTL different ways. (See Control Synthesis Output with Combinatorial Logic in Procedural Code for an example of controlling synthesis with coding styles.) Given this sensitivity, we need to know how synthesis works. The Basic Synthesis Process At its most basic, a hardware synthesis tool does three things: 1. Compiles your RTL and creates a hardware representation of the logic and registers in your design. 2. Converts the generic representation of your design to the target hardware without worrying about timing. Usually the synthesis tool will try to make the smallest design possible at this point. 3. Compares the logic paths in your design to your timing constraints, and works to speed up paths that do not make timing. This is called timing optimization.

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

18

TECHNICAL ARTICLE
Understanding these three steps highlights one of the most important facts about synthesis: if you do not create timing constraints you will probably get the smallest design possible, but you may not meet your timing goals. The three step process also helps us understand what happens when we have very easy timing constraints. Consider the case where your timing constraint is easy to meet because your target chip is very fast and your paths are very short. In that case, the synthesis tool wont find any paths in Step 3 that miss timing, and youll get the smallest possible design with the shortest synthesis time. Understanding these three steps also tells us that overconstraining a design too much is worse than not giving it any timing constraints. Many people make the mistake of thinking of timing constraints in the same way that we think of the accelerator on a car. If you stomp on the accelerator, then the car will work harder and go faster. This is not true with synthesis. If you grossly overconstrain a designfor example, if you set the constraint to two times your target clock rateyou wont make the synthesis tool work harder. Instead your synthesis tool will reach Step 3 and find out that almost none of the paths make timing. It will get to work on the worst offenders, probably paths that were never intended to make 2x timing, and then it will give up before trying to optimize the others. The result? A grossly overconstrained design will actually get worse timing than a design with a modest 10% overconstraint. The timing will be random because the synthesis tool will not know where to focus its efforts and it will give up on the process too early. Understanding Timing Constraints For the most part [1], synthesis tools have a very simple view of your design. They break all designs into three paths (Figure 1): Ports to RegistersThis is logic that goes from the input pins of your module to the input pins of your first registers. Registers to RegistersThis is logic that goes from the output pins of one set of registers to the input pins of the next set of registers. Registers to PortThis is logic that goes from the output pins of the last set of registers to the output ports. The Ports in this diagram can either be the input and output pins of your chip, or they can be the input and output ports of a module. Synthesis views both the same way. When you set a timing constraint on your design, the synthesis tool turns that timing constraint into three constraints. For example, say you want to have a clock speed of 100Mhz. A synthesis tool will break this into three constraints: Port to Register: 10ns Register to Register: 10ns Register to Port: 10ns

TECHNICAL ARTICLE

Port to Register

Register to Register

Register to Port

Register

Logic

Logic

Register

Logic

Figure 1

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

19

TECHNICAL ARTICLE
TECHNICAL ARTICLE

10ns
Port to Register

10ns
Register to Register

10ns
Register to Port

10ns
Port to Register

10ns
Register to Register

10ns
Register to Port

Register

Register

Register

Logic

Logic

Logic

Logic

Logic

Register

Logic

Figure 2

The Register to Register constraint of 10ns is easy to understand. Its the Port to Register and Register to Port constraints that can get tricky. Say, for example, that the signals on your board wont reach your chip for 5ns. If the synthesis tool allows a 10ns Port to Register path, then you will not make timing. The signal will arrive 5ns late and then it wont be ready to settle until 15ns into the clock cycle. You can address this problem two ways: you can either change the Port to Register constraint to 5ns, or you can register your signals as soon as they come into your chip. This is why many FPGAs have registers built into the input pins. Timing, Hierarchy, and Constraints Notice that I described the input and output constraints as Port to Register and Register to Port, not Pin to Register. This is because it is best to think of synthesis tools as focusing on one module at a time when they synthesize [2]. This is an artifact of the memory requirements of timing analysis. Timing analysis can take a lot of memory, and that memory use goes up quickly with the size of the modules. So if a synthesis tool looks at one module at a time, it can handle a large design without running out of memory. This gives us a tradeoff to consider. Lets look at a multimodule design (Figure 2). In this design, I have two modules with 10ns constraints on the paths. If I look at one module at a time I have lower

memory requirements, but I cannot see the relationship between the output path of the module on the left and the input path of the module on the right. This could lead to timing problems. I could get around this by telling the synthesis tool to flatten the designthat is to get rid of all the modules and make one big module. Now my synthesis tool will see all the paths, but it will use a lot of memoryperhaps too much memory for my machine. Modern synthesis tools try to help with this tradeoff by selectively flattening smaller modules, and by using some algorithms that allow them to take the output paths of some modules into consideration when looking at the input paths of downstream modules. But the basic tradeoff still exists. We get the most accurate timing when we flatten the design, but it can take a lot of memory. My advice is two-fold: Register the output of your modules whenever possible to avoid having a noticeable register-to-output path. Let the synthesis tool manage your module hierarchy. If the tool thinks it should flatten the design then let it flatten the design. If you follow these two steps, you will usually get what you expected from your synthesis tool. Summary and Downstream Complications In this article we examined some of the basics of synthesis and we saw how a synthesis tool can create a

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

20

TECHNICAL ARTICLE
netlist that it believes will meet timing. In our next article, well see how this can all go to pot when the netlist runs through the Place and Route tool, and well examine ways to ensure that we meet timing after weve placed our netlist into our FPGA. References [1] I say for the most part because optimization techniques can blur the concepts in this section. That said, the concepts here form the core of synthesis technology. If you think of synthesis in these terms you will be on the right track. [2] There are those who would point out that many modern synthesis tools can consider several modules at once and can optimize across module boundaries. Yes there are. But not all of them can, and it is safest to think of synthesis in this module-by-module way to understand the tradeoffs. About the Author Ray Salemi is a veteran of the EDA industry and has been working with Hardware Description Languages since he joined Gateway Design Automationthe company that invented Verilog. Over the course of his career he has worked at Cadence, Sun Microsystems, and Mentor Graphics. Ray is currently an Applications Engineer Consultant with Mentor Graphics.

TECHNICAL ARTICLE

ACOUSTICS & SENSORS

PRODUCTS
Speakers Buzzers Piezo Elements Back-up Alarms Horns Sirens/Bells Beacons Microphones Sensors

BeStar
INDUSTRIES
Automotive Durables Medical Industrial Mobile Fire / Safety Security Consumer Leisure

Teamwork Technology Invention Listen Hear

Preferred acoustic component supplier to OEMs worldwide

bestartech.com | sales@bestartech.com | 520.439.9204

EEWeb | Electrical Engineering Community Visit www.eeweb.com QS9000 TS/ISO16949 IS O 14001 IS O 13485 IS O 9001

21

Get the Datasheet and Order Samples

http://www.intersil.com

Dual 14-Bit, 250/200/125 MSPS JESD204B High Speed Serial Output ADC
ISLA224S
The ISLA224S is a series of low-power, high-performance, dual-channel 14-bit, analog-to-digital converters. Designed with FemtoCharge technology on a standard CMOS process, the series supports sampling rates of up to 250MSPS. The ISLA224S is part of a pin-compatible family of 12- and 14-bit dual-channel A/Ds with maximum sample rates ranging from 125MSPS to 250MSPS and shares the same analog core as Intersil's proven ISLA224P series of ADCs. The family minimizes power consumption while providing state-of-the art dynamic performance, offering an optimal performance-vspower trade-off. Differentiating the ISLA224S from the ISLA224P is its highly configurable, JESD204B-compliant, high speed serial output link. The link offers data rates up to 4.375Gbps per lane and multiple packing modes. It can be configured to use two or three lanes to transmit the conversion data, allowing for flexibility in the receiver design. The SERDES transmitter also provides deterministic latency and multi-chip time alignment support to satisfy an application's complex synchronization requirements. A serial peripheral interface (SPI) port allows for extensive configurability of the JESD204B transmitter including access to its built-in link and transport-layer test patterns. The SPI port also provides control for numerous additional features including the fine gain and offset adjustments of the two ADC cores as well as the programmable clock divider, enabling 2x and 4x harmonic clocking. The ISLA224S is available in a space-saving 7mmx7mm 48 Ld QFN package. The package features a thermal pad for improved thermal performance and is specified over the full industrial temperature range (-40C to +85C).

Features
JESD204A/B High Speed Data Interface - JESD204A Compliant - JESD204B Device Subclass 0 Compliant - JESD204B Device Subclass 2 Compatible - Up to 3 JESD204 Output Lanes Running up to 4.375Gbps - Highly Configurable JESD204 Transmitter Multiple Chip Time Alignment and Deterministic Latency Support (JESD204B Device Subclass 2) SPI Programmable Debugging Features and Test Patterns 48-pin QFN 7mmx7mm Package

Key Specifications

SNR @ 250/200/125MSPS 73.2/74.1/75.1 dBFS fIN = 30MHz 70.7/70.7/70.6 dBFS fIN = 363MHz SFDR @ 250/200/125MSPS 82/91/94 dBc fIN = 30MHz 77/79/67 dBc fIN = 363MHz Total Power Consumption: 989mW @ 250MSPS

Applications
Radar and Satellite Antenna Array Processing Broadband Communications and Microwave Receivers High-Performance Data Acquisition Communications Test Equipment High-Speed Medical Imaging

Pin-Compatible Family
MODEL ISLA224S25 ISLA224S20 ISLA224S17 ISLA224S12 ISLA222S25 ISLA222S20 ISLA222S12 FIGURE 1. SERDES DATA EYE AT 4.375Gbps RESOLUTION 14 14 14 14 12 12 12 SPEED (MSPS) 250 200 170 125 250 200 125 PRODUCT AVAILABILITY Now Now Soon Soon Soon Soon Soon

December 20, 2011 FN7911.0

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

A System Perspective on Specifying Electronic Power Supplies:

Source Characterization
Last time we discussed the effects of load characteristics upon power supply specification. This month we will learn about important source characteristics for power supply specification. Figure 1 shows a power supply in a very simplified form, connected to a simplified source. The voltage source shown is ideal. The illustrated source impedance represents the combination of the non-ideal voltage source impedance and the impedance of the conductors carrying current from the voltage source to the power supply input. Power supplies must accommodate not only the ideal characteristics of the voltage source, but also the effects of the source impedance upon the power quality at the power supply input. Additionally, the power supply must satisfy regulatory requirements for its effective impedance such that line current distortion does not exceed regulatory limits. Source Voltage AC Sources Real world voltage sources can be alternating current (AC) which means that the current reverses direction a specified number of times per second. However, it is the root mean squared (RMS) voltage which is quantified. Across the world, the nominal utility RMS voltages range from 100V in Japan to 240V in several countries. In most countries, the voltage at the source has a +/- 5% tolerance. Typical voltage drops on the lines range up to 5% due to utilization. Therefore the voltage seen by the user is typically in the range of +5% to -10% of nominal. This means that across the world, the low line RMS voltage at the point of usage can be as low as 90V (Japan), or as high as 252V. One exception is Afghanistan where the RMS source voltage can range as high as 280V. As a result of the proliferation of electronic loads, large peak currents exist at the peak of the utility voltage sine wave. These peak currents create large voltage drops across the source impedance resulting in distortion of the sine wave at the peak. The result is that the measured peak voltage at the point of use is somewhat less than what an undistorted sine wave would be.

Power Supply Design Consultant

Bob Stowe

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

23

TECHNICAL ARTICLE
Source Impedance Line Current
TECHNICAL ARTICLE

Voltage Source

Power Supply Input Voltage

Effective Power Supply Input Impedance

Figure 1: Simplified representation of power supply and source.

This effect must be accounted for in the design of power supplies. The power supply must be specified to accommodate all of these effects. Specification of power supply requirements should include the factors of RMS voltage range at the points of use. It is helpful to also provide minimum peak voltages to provide information on utility voltage distortion. DC Sources Direct current (DC) comes from a source which normally does not reverse polarity. Pulsating current or voltage is still considered DC as long as the current does not reverse direction. Practically speaking, a DC source is primarily a steady DC level with little or no ripple component. In the ideal case, a DC source is a special case of an AC source where the frequency is zero. DC sources usually have a nominal value with a specified tolerance around the nominal. The power supply must be specified to accommodate this range.

Frequency Nominal frequencies that power supplies must commonly accommodate are DC, 50Hz, 60Hz, and 400Hz. Aviation applications commonly use 400Hz. The utility grid frequency tolerance is very tight, about +/- 0.02Hz. For the case when there is a utility power outage, the power supply must be specified to accommodate the tolerance of any standby generators installed. The usual tolerance for this case is +/- 3Hz. For aviation requirements for 400Hz power, the tolerance is +/- 7Hz. See MIL-STD-704F for details. Phase Count Power is provided in either singlephase for lower power demands or three-phase for industrial power demands. Three phase usage can provide much greater power to the load because the associated line currents are much less, resulting in much lower I2R losses in the cables and connections. If a source is three-phase, the power

supply could be single-phase, tapping off just two of the lines. However, this method results in unbalanced usage of the available power, which creates undesirable currents in the neutral conductor. Furthermore, the power supply cannot extract as much power from the lines. If three-phase power is provided, it is better for the power supply to have a three-phase front end to use the available three-phase power. Source Impedance In this article, source impedance refers to the combination of the actual source and the line impedance as seen from the point of use. This impedance can be a combination of resistance, inductance, or even capacitance. The source impedance is responsible for utility line voltage distortion at the peak when electronic loads pull large peak currents through the impedance. This distortion is typically caused by other electronic loads in parallel with your load on the utility grid.

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

24

TECHNICAL ARTICLE
Particularly with DC sources, if the source impedance is not low enough, and at heavy current draw by the power supply, the voltage drop along the lines can be great enough to disrupt power supply operation unless the power supply is designed to accommodate the drop. This problem is common with a switch mode power supply during turn-on when the current draw is the highest. It is possible for the switch mode supplies with under voltage lockout features to cycle on and off due to this problem unless there is sufficient under voltage lockout hysteresis built in. The power supply must be specified to accommodate the source impedance characteristics. Source Transients There are some adverse conditions on the source which need to be considered as to how the power supply should handle them. Blackout/Momentary Loss of Power For short duration loss of power up to several line cycles, power supplies can often be designed for a hold-up time, during which power is drawn from an energy storage reservoir such as a capacitor. For longer duration transients, batteries must be used to provide this reservoir of energy. The power supply holdup time should be specified in the event of a power loss. Brownout A brownout is typified by a source voltage reduction below the specified tolerance range from nominal. Normally power supplies have plenty of margin to accommodate minor brownouts. However, if the brownout is severe, the source voltage at the point of use can go below the capability of the power supply. Brownouts can be ignored or accommodated either by specifying the power supply to operate at a lower input voltage, or by resorting to a battery backup. The brownout duration that the power supply must ride through should be specified. Lightning and External Inductive Kick Transients Lightning or external inductive loads can cause line voltage transients capable of damaging electronics. Power supplies can be designed to tolerate transients of various durations and magnitudes using various different methods. The most common method in consumer electronics is to use transient suppression devices such as varistors, transorbs, and spark gaps across the input. These types of devices assume that the majority of the energy in the transient is absorbed by the impedance of the line while the device itself simply clamps the voltage. The device must be rated to handle the small amount of energy that is not absorbed by the line impedance. This method does not always work because it is difficult to design for all line impedance conditions. Another method is to use a voltage blocking device such as a power MOSFET to switch off the power supply for the duration of the transient. As long as the voltage rating of the blocking device is not exceeded, the transient energy will most likely be absorbed somewhere else. Another possibility is for the power MOSFET to pass power to the power supply while continuing to block the transient. The possible danger here, in addition to exceeding the voltage rating of the MOSFET, is exceeding the safe operating area rating of the device. For any of these transient protection methods, the transient should be understood, the line impedance should be known, and the power supply should be specified to accommodate them. Automotive electronics has some of the more severe transients to endure. SAEJ1113-11 and ISO 7637 contain test transients for automotive electronics. Source Rise Time Occasionally, source rise time, whether fast or slow, is an issue. It should be specified as one of the power supply requirements. Regulatory Requirements Harmonic Content Regulation Power supplies employ rectifiers to change AC voltage to DC voltage. In most practical circuits today, this is a highly non-linear process causing great distortion of the line current. This distortion of the line current causes a large voltage drop across the source impedance resulting in line voltage distortion at the point of use. In the interest of preserving utility line voltage quality, power supplies must now meet regulatory requirements. Line connected electronic power supplies above a certain power level must now employ power factor correction circuits to remove this distortion. The goal of power factor correction is to align the current drawn by the power supply with the line voltage.

TECHNICAL ARTICLE

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

25

TECHNICAL ARTICLE

EEWeb
Electrical Engineering Community

TECHNICAL ARTICLE

Join Today
www.eeweb.com/register

When the shape of the line current is the same as the line voltage, the power supply looks like a resistor to the line and the power factor is very near oneno distortion. For lighting circuits, power supplies above 25W require power factor correction. For most other power supplies, the power level above which there must be regulation is 75W. See IEC 61000-3-2 for details. Electromagnetic Compatibility Electronic equipment typically has signals with very fast signal transitions. These transitions propagate via conduction on the power leads to the source and via radiation to the environment and have disruptive effects on other equipment in the vicinity. There are several standards gov-

erning electromagnetic emissions. Applicability of standards is generally a function of the country the product is to be marketed in. If the product is to be marketed worldwide, then there will be numerous standards to satisfy. About the Author Bob Stowe has over 21 years of experience in various disciplines related to electronic energy conversion, possesses a masters degree in power electronics, and is a member of IEEE in good standing. He also has obtained his certification in power electronics from the University of Colorado (COPEC). Additionally, he graduated from the United States Naval Academy in 1984 with a bachelors degree in electrical engineering, and served for five subsequent years as a United

States Naval Officer. As a former military officer, he is familiar with military project requirements. Bob works for True Power Research as a Power Supply Design Consultant.

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

26

RETURN TO ZERO
RETURN TO ZERO

EEWeb | Electrical Engineering Community

Visit www.eeweb.com

27

RETURN TO ZERO
RETURN TO ZERO

EEWeb
Electrical Engineering Community
Contact Us For Advertising Opportunities

advertising@eeweb.com www.eeweb.com/advertising
EEWeb | Electrical Engineering Community Visit www.eeweb.com

1.800.574.2791

28