EEWeb Embedded Developer: IAR Systems

Page 1

All in One

A Look at the Compiler and Debugger Toolsuite: IAR Embedded Workbench

Buy vs.

Build

Stefan Skarin

CEO of IAR Systems


Your Guide to Embedded MCUs and Development Tools. Everything you’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

8 14 30 34

TECH COLUMN

RASPBERRY PI PRIMER PART 4: SETTING UP A SIMPLE SERVER

COVER INTERVIEW

STEFAN SKARIN - CEO OF IAR SYSTEMS Functional Safety Tools for Renesas RX

IAR Systems provides a toolset for developing safety related applications using the Renesas RX family of MCUs. The software is a complete development tool suite including the IAR C/C++ Compiler, assembler, librarian, linker, text editor, project manager, and C-SPY Debugger.

IAR Embedded Workbench

IAR Embedded Workbench is a development environment that helps the user generate faster code than ever before. The software incorporates a compiler, assembler, linker, and debugger into one integrated development environment, offering the user an all-in-one solution that provides a seamless development workflow. IAR Systems guarantees a powerful, userfriendly, and reliable product that enables the user to develop new competitive products with no tool qualification time necessary. With the certified versions of the tools, an exhaustive functional safety support and update agreement is offered.

PRODUCT HIGHLIGHT Additional Features:

• Extensive support for RX devices • Renesas RX ABI Compliant • Elaborated compliance with language standards • Integration with Subversion and other source code control systems • Integrated MISRA-C rule checker

IAR EMBEDDED WORKBENCH TOOLSUITE Standards and Certification

Embedded applications used for safety critical functionality needs to fulfill certain requirements and be certified by an independent agency according to the relevant industry standard. Common standards are IEC 61508, the international umbrella standard for functional safety, and ISO 26262, which is used for automotive safety-related systems. High-integrity standards frequently require you to provide extensive justification for selecting a particular development tool. The proof of compliance for the tools increases cost and time of development, unless the tool is already certified.

TECH ARTICLE

BUY VS. BUILD: ADVANTAGES OF A MODULAR DESIGN

TECH ARTICLE ACHIEVE SEAMLESS VOLTAGE-LEVEL TRANSLATION

EMBEDDED WORKBENCH FEATURED ARTICLE KEEPING SAFE AT C: A C-PROGRAMMING TUTORIAL

4 13 20

3


Achieve Seamless Voltage-Level Translation with the Best Possible Noise Margin Operate well at the 1-volt node and translate from 1-volt to as high as 5-volts.

As microprocessors have matured, we’ve moved from the 5-volt (5V) technology developed in the 1970s, to the 3.3V in the 1990s, the 2.5V in the 2000s, the 1.5V and 1.25V in the past five years, and, most recently, the 1V. These advantages have led to device innovation, especially in mobile markets. Unfortunately, if you design an architecture using parts that come with different voltages, those parts cannot connect directly because the higher voltage will stress the parts that operate on the lower voltage. Most engineers have encountered this problem when designing mobile device architectures. This leads to delays in production while workarounds are sought because if the problem is not resolved, the mobile device will not function.

4


TECH ARTICLES

What’s required: bus buffers that act as voltage-level translators that come with two voltage supplies and that can translate voltage from one to the other and back again. But not just any bus buffers will do because electrical noise can NXP: Leading Voltage-Level Translators with Generous Noise Margins NXP’s family of bus buffers are the solution. They simplify interconnection of processors running at one voltage level to I/O devices operating at a different voltage level. For example, some processors might be at 1V, while other devices on the bus are at 3.3V, while still others are at 5V. NXP voltage-level translators can seamlessly translate from as low as 1V to as high as 5V.

Quick Take: What to Look for in a Voltage-Level Translation Buffer Not all bus buffers offer voltage-level translation. Make sure that you choose the latest two-supply devices to bypass traditional capacitance limitations. Look for the devices that provide seamless voltage-level translation with the best possible noise margin.

I2C Bus Use Beyond 400pF Maximum Capacitive Loading

Applications

Bus buffers allow designers to expand use of the I2C bus beyond the 400pF maximum capacitive loading allowed by the I2C specification by dividing the bus into <400pF segments. The bus buffers enable bidirectional communication without a direction pin.

• Add more I2C or SMBus devices in the same system. • Extend the reach of I2C or SMBus over longer distances. • Isolate an I2C or SMBus segment. • Translate voltage levels to allow devices with different voltage requirements to work on the same bus. • Electrically isolate the I2C bus. • Support multipoint distribution of the I2C bus.

In situations where voltage-level translation is necessary, engineers usually can’t use simple FETs (field-effect transistors) because threshold noise margin—that is, the amount of signal that a circuit can withstand—can be a concern at low voltages. Thanks to innovations at NXP, these challenges have been largely alleviated. Bus buffers from NXP isolate capacitance on the I2C bus and also allow better voltage-level transla- tion. Possessing two supply pins, they actively drive the lowlevel signals.

5


2014 AXP Design Contest Here’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 • 1 First Place Winner 1 Second Place Winner • 1 Third Place Winner

er Logic and Your High Power Creativity.


The Raspberry Pi Primer Part 4: Setting Up a Simple Server by Kyle Olive, EEWeb Contributing Author

At this point in the series, you’ve set up Arch Linux ARM on your Raspberry Pi and you are ready to turn it into something. In this article, you’ll set up a Raspberry Pi as a simple local network server that can serve up web pages and act as an FTP server. This article will only explore setting up the server for use on local networks, not through the internet.

8


TECH ARTICLES If you haven’t already set up the “sudo” software and a separate non-root account on your Raspberry Pi, and you plan to have it accessible to the public on a network, I would recommend you do so. You don’t want people to have root access to your Raspberry Pi over the network; they could seriously mess with your setup or steal your files. There are plenty of good resources online for setting up sudo. A setup guide is available here for Debian. We’re using Arch Linux ARM, but the process is mostly the same (note: you have to use pacman on Arch instead of apt-get to install the software).

You’ll then want to change the file to contain the name by which you want your Raspberry Pi known. In this example, my Raspberry Pi will be known as “webpi”. Any time you see the name “webpi” for the remainder of this article it should be replaced with whatever you’ve decided to call your server.

Also, if you’re not familiar with command-line text editors like vi or nano, you can find many quick references online. One such reference for Vi is located here.

Do so by inserting the lines reading:

Hostname Setup

to be:

You’ll need to define a hostname that you will use to refer to your Raspberry Pi Server. You’ll want to edit your hostname configuration file, located at /etc/hostname, using any text editor. For example you can use:

127.0.0.1 localhost.localdomain localhost webpi 1 localhost.localdomain localhost webpi

vi /etc/hostname

Once you edit the hostname, you should also edit the hosts file to let the Raspberry Pi know that it should refer to itself with that name. This time we want to edit /etc/hosts . You want to add 127.0.0.1 and ::1 as webpi.

127.0.0.1 localhost.localdomain localhost 1 localhost.localdomain localhost

To ensure your setup is complete, restart your Raspberry Pi, and then attempt to ping your hostname locally using the command ping webpi.

FileZilla after connecting to the SFTP server on your Raspberry Pi

9


Note: Depending on the quality of your router, you may be able to skip this step. Try pinging webpi before editing your host file on your client machines. Now, get your local ip address by running the “ifconfig” command. It will most likely be of the form 192.168.. if you’re using a local home network. Make note of the ip address. If that is successful, hop onto another computer on the local network and attempt to ping the local IP address of the Raspberry Pi that you have noted down. If it works and you get a response, add that IP address to your hosts file on the machine you’d like to access the server from. If you’re using Windows, you want to edit C:/ windows/system32/etc/hosts, and on Linux you want to edit /etc/hosts. Add the line: <LOCALIP> webpi

10

Try to ping again by using the “ping webpi” command. Hopefully it will work. If you’re stuck on this step, have a look at your router’s settings to make sure it isn’t interfering.

Apache Setup Now that we can access our Raspberry Pi on the network, we only need to setup a webserver to be able to serve web pages. A very common webserver is Apache. Install Apache on your Raspberry Pi by using pacman: pacman -S apache Before we start the webserver, we may want to configure Apache. To do so we must write the configuration files that Apache will use to run the server. Navigate to /etc/httpd/ conf. This is the folder that Apache stores it’s configuration files. We’ll want to edit httpd. conf, which is the main configuration file for Apache. The default settings will usually work for most applications. If you want you can go through and change settings as desired. For example, you may want the DocumentRoot (the folder the web server points to when serving files to a client) to be pointed to a different folder.


TECH ARTICLES Once that is completed, you can run httpd. This will start the HTTP Daemon which will serve web pages up to clients. To ensure it’s working, hop on another computer on your local network and enter webpi into the URL bar. You should get a page titled: “Index Of /.”

<Your Pi password> port: 22

At this point, we have a basic functional web server. If you haven’t changed the DocumentRoot of Apache then putting the following HTML into an HTML file somewhere in the folder /srv/http will make that webpage accessible through a browser by navigating to:

Configuring the Services to Autostart

http://webpi/filename.html You’ve now set up a simple web server that you can use to make pages accessible to anyone on the network. While this isn’t useful on it’s own, it allows you to set up a numerous amount of web applications. There is a ton of open source stuff online, everything from open source scheduling software to project management tools. Having these applications available for free from any computer on your local network is a definite asset. (That being said, for many of these tools you will need to install a full Web Server Stack. For more information see: http://en.wikipedia.org/wiki/ LAMP_(software_bundle))

Setting up an FTP Server You may also want to set up an FTP server to allow you to easily upload and download files from your Raspberry Pi. After setting up FTP access to your Pi on the local network, you can use it as a central storage location in your home or workplace. Attaching an external USB hard-drive to your Raspberry Pi can allow you to store a lot of files in a way that’s easily accessible to anyone that has access.

If everything is working the login should work, and you’ll be able to upload and download files to and from your Raspberry Pi.

Last but not least, make sure that your server services are configured to automatically start when the Pi is powered on (this way you don’t have to turn them on manually every time the power goes out). In order to do that, use the following command: systemctl enable httpd.service systemctl enable sshd.service The previous two commands tell Arch to enable httpd and sshd, our web and SSH/FTP servers, as system services, and they should now automatically start on boot.

Conclusion Now you’ve turned a Raspberry Pi with Arch Linux ARM into a local network server that you can use to store information, data files, and more. ■

To read the previous installment, click below:

The easiest way to set up an FTP server is to install OpenSSH. Do so using pacman -S openssh Restart your Raspberry Pi and you should now be able to access your Pi’s filesystem using any FTP client. One graphical client is FileZilla. You can connect to your Pi using the following credentials: hostname: <Your Pi’s Hostname or local IP Address> login: <Your Pi login> password:

11


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

n

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

ie


EMBEDDED WORKBENCH RX600 Direct-Drive Demo Kit RX Direct-Drive Solution Kit for TFT LCD: • Everything you need to design a LCD based solution in one package • Graphic rich demo that runs Out Of the Box • Easy to install development tools • Free graphics API, library, schematics and examples for evaluating graphics Utilizing the external DMA to drive the TFT-LCD and move the RGB data greatly reduces the load on the MCU´s core, maximizing the performance of the MCU to run the application software. There is only a 5% loading on the CPU when refreshing a 60Hz panel. This means that there is over 150DMIPS left over to run an RTOS and communications protocols, drive motors and, if required, create animations.

Freedom Development Platform The The Freescale Freedom development platform is a set of software and hardware tools for evaluation and development. It is ideal for rapid prototyping of MCUbased applications. The Freescale Freedom KE02Z hardware, FRDM-KE02Z, is a simple, yet sophisticated design featuring a Kinetis E series MCU, the industry’s first 5-volt MCU built on the ARM® Cortex™-M0+ core. Features: • MKE02Z64VQH2 MCU – 20 MHz, 64 KB Flash, 4 KB SRAM, 64QFP • Capacitive touch slider, MMA8451Q accelerometer, tri-color LED • USB or external power supply options • Easy access to MCU I/O • IrDA transmitter and receiver

Wi-Fi Comm Demo Board Wi-Fi Comm Demo board provides a compact development platform for customers to evaluate Microchip’s Wi-Fi product offering. The demo board comes with onboard MRF24WB0MA Wi-Fi module which is FCC/IC/ETSI certified along with a PIC32 MCU. Features: • WiFi solution compatible with IEEE 802.11 b/g/n Access Points • Supports Infrastructure and Ad hoc networks • MRF24WB0MA module is FCC, IC, Wi-Fi® certified and ETSI compliant • Powered by 2 AAA batteries • Supports WEP, WPA and WPA2 security protocols

13


14


COVER INTERVIEW

IAR: SYSTEMS

Leaders in Embedded S o f t wa re

Interview with Stefan Skarin, CEO

IAR Systems is the world's leading provider of software for processor programming in embedded systems. Founded in 1983, IAR Systems launched the world's first C compiler for the 8051 microprocessor, which was an instant success in the industry and aided in the company's growth. The company's most popular product, IAR Embedded Workbench, was introduced to the market 10 years later in 1993 and offered engineers an all-in-one compiler and debugger solution. Since then, IAR Systems has accumulated over 100,000 dedicated users and many partners, allowing them to extend their reach from a local Swedish company, to a global software provider. Embedded Developer spoke with Stefan Skarin, the CEO of IAR Systems, about some of the new features added to IAR Embedded Workbench, why the product's industry certifications are beneficial to the user, and why many customers are standardizing on IAR Systems' products.

15


From the world’s first C compiler to the world-leading IAR Embedded Workbench software, IAR Systems has gained a reputation for user friendly, functional, and robust embedded software tools. ■

Could you talk about IAR Systems as a company and some of the products you offer? We actually celebrated our 30th anniversary two months ago. We have basically been doing the same thing the whole time, and that is development tools for microcontrollers. 30 years ago, we started out developing a compiler for the 8051 core and as you probably know, it was really the first core that was used in mass-market for embedded systems. Since then we have been developing compilers for different microcontrollers on requests from the silicon vendors. We developed compilers for ST, Texas Instruments, Freescale, Atmel, Energy Micro, Renesas, and more. During our first 25 years, the business model was selling development contracts to the silicon vendors. In 2006, we started to change our focus to the customers using our development tools and by 2009, we became a full-fledged software company with a clear offering of tools and support services for the embedded market space.

16

When we talk about the product, it is basically the same product since the start of the company in 1983—it’s called IAR Embedded Workbench. It is a development tool suite that consists of a compiler, a debugger, and an IDE that makes the interface easy to use for all of our customers. The change we have had in the last few years is that we are now fully concentrated on the users and the companies they work for: Boeing, Siemens, Honeywell, Microsoft, Bosch, Continental, Johnson & Johnson, and so on. Today, we have 46,000 active companies as customers— and by active; I mean they currently have a license that is being used. In total, we have sold over 130,000 licenses over the years.

What is IAR Embedded Workbench? What are its strengths and why do customers choose to use it over other compilers? What I did as the new CEO back in 2009 was to ask for customer feedback on our product. I discovered that IAR Embedded Workbench


COVER INTERVIEW is known for its stability, ease-of-use, and reliability. What I also noticed was that we had a very good track record for technical support because we have offices with experts all over the world. The customers felt really safe using our tools. With IAR Embedded Workbench, there is a focus from our development team to really get you up and running quickly. We have more than 4,300 example projects in the product, and we support more than 8,000 different devices. You should be comfortable whenever you select a microcontroller for an embedded product that you have the support to back it up. Thanks to our 30 years in the industry, we offer a unique technology and by supporting as many cores as we do, the fact is that you can reuse code between different architectures and even between 8-16-32 bit projects. If you take the performance side of the product, the focus over the years has been on the size of the code. The C-program that is compiled should occupy a small space on the microcontroller itself. That is what we were originally known for. Over the last few years however, there has been a lot of focus on low-power applications. All of the silicon vendors come to us asking us to work with small power usage to support low power applications. Power usage is a huge focal point for them and that has led to a huge interest in speed. Not only should the code be small, it should also be fast and powerful, because if it is, it will result in power savings. Today, we have achieved world record performance for several ARM cores.

When it comes to safety certification, stability is very important. How important was it for IAR Systems to make sure IAR Embedded Workbench was TUV certified? If you look at trends in the industry, you will see that application complexity is really growing. It’s getting more and more complex for the developer. One customer came to us because they were starting an ARM project and they had 400 pages of documentation with different scripts they needed to follow in order to start the project. A car manufacturer approached us recently and told us that they needed to maintain a car for 25 years, and it’s not about mechanical problems anymore,

“With IAR Embedded Workbench, there is a focus from our development team to really get you up and running quickly.”

17


“ The main benefit for our customers to standardize on our development tools is the reuse of code between microcontrollers.�

18

the issues are with electronic problems that could occur in the car. So suppliers to car manufacturers have to have a product that is actually certified for the car for 25 years. Maintaining a product for 25 years is tough, but to have it certified is even tougher. We see a trend that many market segments are interested in certification. Many of our customers want their products certified, and the starting point for that is to give them an environment to certify the tools, so now the starting point they have is start-and-go.

What does IAR Systems offer in terms of customer support and services? We currently have three offices in the U.S.—on the East coast, the West coast, and in Dallas. We have a representational office in Brazil. We have a few offices in Germany, France, and the UK. We also have offices in Korea, China, and Japan.


COVER INTERVIEW

In all of these offices, we have support people, and we have sales people. We of course also have support staff at our headquarters in Uppsala, Sweden. We are very keen on having superior support in all of our offices.

Why should a company standardize on something like IAR Embedded Workbench? Back in 2010, when I started to visit plenty of customer sites, I saw a trend with them that they were running with 8, 9, 10, even 12 different microcontrollers. They could have a Freescale, an ST, and a number of other microcontrollers with a lock-in to proprietary systems. The trend that ARM started is that all the silicon vendors are now into ARM, and for customers like ours, it’s the perfect situation, because they can select for example a Cortex-M3 and then have multiple vendors to choose from. I have seen a trend with a lot of customers moving to fewer microcontrollers—they don’t want to maintain 10 different microcontrollers, they want three to four. They are actually minimizing the portfolio to save money and maintain the products with less need for support. I think that was the legacy that we started—we started with 8-bit and we moved into 16-bit, and I saw a lot of customers taking their code from an 8- or 16-bit environment, and making it more complex by adding a touchscreen or wireless connectivity. When they use our product, they can reuse code within the different environments. I talked to customers about what they were really looking for and they said that ARM was giving them flexibility, and that they needed a flexible, seamless development workflow. They couldn’t be locked up in a proprietary system—they needed to be able to move around. I offered a few customers at the very beginning the opportunity to standardize on our tools so that they could move between different cores from 8-, 16- to 32-bit, and move between Freescale and Atmel, and between TI and Renesas. If they used the

“IAR Systems is a 30-year-old company with a stable product offering, experienced employees and loyal customers, but we are also transforming and taking new positions due to our increasing ambitions.” same tools, they could reuse their code. This became a concept that I got into my mind, and I started writing a few articles about it back in 2010 and that worked out fine. We started to offer an enterprise agreement to assist our customers to more flexibility in their development environments. The main benefit for our customers to standardize on our development tools is the reuse of code between microcontrollers, but they also gain things like extended services and support, and even financial benefits. I called this “Standardization without limitations.” It was mainly done for ARM, so we developed it focusing on ARM customers but have lately also included Renesas customers in our quest for more enterprise relationships. As a final note, I just want to express that IAR Systems is a 30-year-old company with a stable product offering, experienced employees, and loyal customers, but we are also transforming and taking new positions due to our increasing ambitions. I want to do more─much more─for IAR Systems and the embedded market. ■

19


C

Keeping Safe at

20


C

FEATURED ARTICLE

How to Neutralize Some of the Inherent Dangers of C This article will take a look at the issues involved in using C in the development of systems with safety-critical functionality. Despite the fact that the language is full of undefined behavior, hardware dependencies and other pitfalls, it is still a widely used and popular language in the field of safety-critical development. With some forethought and planning, we can turn a potential problem into an advantage.

21


C 1. Move your feet

Already back in 1991 the magazine Developer’s Insight published an entertaining article titled “How to Shoot Yourself In the Foot” that started out: “The proliferation of modern programming languages (all of which seem to have stolen countless features from one another) sometimes makes it difficult to remember what language you’re currently using. This guide is offered as a public service to help programmers who find themselves in such dilemmas.” The list of languages starts with C and simply states: • C - You shoot yourself in the foot.

This verdict might seem a bit harsh, but holds more than just a grain of truth. But if we look at alternative programming languages that can be used for embedded systems development we often find that although the languages often are cursed with far less problems in terms of type safety, undefined behavior etc, they often lack in features for programming close to the metal. So if we stick with C we need to strike a balance, navigating between the obvious and not so obvious pitfalls and still making the best use of the language features. In the following we will look at C as a language for development of safety critical functionality from two different perspectives: • What kind of external requirements will you find yourself subject to in a project with safety critical functionality with respect to the choice of programming language? • What can you do to remedy some of the more blatant issues with C, also when working with legacy code?

2. Standard reply

If the products you are working on have a place in for example automotive, industrial control, medical devices, railway or any other of a number of niches there’s a fair chance that they already are or will be subject to formal functional safety requirements.

22 22

Such requirements can boil down to a very specific requirement on the tolerated failure rate of your product, or the allowed failure rate of some very specific functionality in your product that provides safety to the operator, innocent bystanders or property. But it can also be a more general requirement that the product should be developed in accordance with a specific functional safety standard, like IEC61508 (electric and electronic programmable devices), ISO26262 (automotive) or EN 50126x (railway). It has been a clear trend for at least the last 10 years that implementation of safety functionality is moving away from pure mechanics or PLC controlled automation and into the microcontroller world and thus functional safety requirements are spilling into the software domain. Since the requirements posed on software by the various standards are similar in intent we will use IEC61508 as an example, because this standard is an umbrella standard that provides the foundation for many sector specific standards; so requirements that are valid for IEC61508 will to a large extent be valid also for ISO26262 for example.

The tricky thing with these standards is that they will heavily influence the way you work and document your work; all the way from requirements gathering to how you plan for deployment and decommissioning of the product at customer sites. Further, it is not you and your project stakeholders alone that decide if you have succeeded in achieving the objectives in a chosen standard – You also have to convince a third party assessor from an accredited body or someone in your organization acting the part. Most of these standards use variations of the safety integrity level concept to capture both the level of accepted failure rates of safety related functionality and the process and development activities needed to fulfill the failure rate claim. So depending on how you, customers or legal requirements classify your product there will be some variation in how you apply the appropriate standard.


C

FEATURED ARTICLE

IEC61508 use four Safety Integrity Levels, named SIL 1 to SIL 4, where SIL 1 is the easiest one to fulfill and SIL 4 is very hard to achieve. An example of a SIL 1 application might be an emergency stop functionality of some appliance where the potential failure of the emergency stop might for example only results in minor bruises for the operator. Typical SIL4 applications are railway signaling or nuclear power plant control where the risk to lives and property is very high in case anything goes wrong.

3 Standards apply? So, this was a very long introduction to get us to the interesting question: What does all this have to do with my choice of programming language? Quite a lot, it turns out. The table above is taken from IEC61508 part 3 appendix A and gives advice on how to select a suitable programming language depending on the safety integrity level of your application or safety function – HR is short for Highly recommended and although it might sound like it gives you freedom in language selection, in standards lingo it is actually a very strong indication that you should follow the recommendation or have a very good reason not to, i.e. a justification that you can back up a 100%.

3.1 Say what? As you can see in the table it is highly recommended to use a suitable programming language, which does not really make a lot of sense as far as recommendations go, does it? But if one follows the reference to the C appendix given in the table it has the following definition of a suitable programming language: The language should be fully and unambiguously defined. The language should be user- or problemorientated rather than processor/platform machineorientated. Widely used languages or their subsets are preferred to special purpose languages. The language should encourage the use of small and manageable software modules; restriction of access to data in specific software modules; definition of variable sub-ranges; and any other type of error-limiting constructs. So let’s look at the various parts of the above definition and how C stacks up to them: • The language should be fully and unambiguously defined: Well, depending on how you count it can be argued that C99 contains at least 190 undefined behaviors.

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 23


46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 24

• The language should be user- or problemorientated rather than processor/ platform machine-orientated: Hmm, given that C was originally created to be a system development language for the PDP-11 architecture with features and data types specifically chosen to match the hardware; and given that a specific C implementation for a specific target is bound to be different from the implementation on a different target and sometimes even different to an alternative implementation for the same target, we cannot really claim that C is compliant with this part of the definition of a suitable language. • Widely used languages or their subsets are preferred to special purpose languages: At last, something we can claim is true for C! There are a huge number of developers out there that knows C or any of its cousins like C++. • The language should encourage the use of small and manageable software modules; restriction of access to data in specific software modules; definition of variable sub-ranges; and any other type of error-limiting constructs: Although C does not explicitly forbid the creation of abstractions that support these concepts it can be said outright that the language in itself does absolutely nothing to support them either. In fact, it can even be argued that the exact opposite is true. So it’s an understatement to say that C does not really live up to the expectations in the standard. The question is of course what we can do about it? Actually, the answer is quite simple, at least as long as we are only reading the standard. If we read on in IEC61508, part 7, appendix C we will find a table with judgments on specific languages and this is what it says for C:

9 10

As can be seen C is not a recommended language except for SIL 1 applications, but C with a suitable subset is even a highly recommended language if used together with a coding standard and static analysis tools. So, what does subset and coding standard mean in this context?

4. Substandard The aim of a language subset, at least in the context of IEC61508, is to reduce the probability of programming errors and to increase the likelihood of finding such errors that has crept into the code base anyway. So for C this means eliminating the use of as many as possible of the undefined or implementation defined behaviors in the language. There are a number of such language subsets available but the most widely known is probably MISRA C, which is now in its third incarnation (MISRA C:2012). Here we will however focus on MISRA C:2004. The MISRA rule set started out as an initiative by the Motor Industry Software Reliability Association in the UK and was aimed solely at automotive software. Over the years adaption of the MISRA rules has spread over the world and into other industry segments, and the rule set from 2004 is now probably the most widely used C subset in the embedded industry. Ok, so let’s say that we chose to adopt MISRA C:2004 as our language subset – What about a coding standard? IEC61508 has quite a lot to say on the coding standard issue as well. Section C.2.6.2 in IEC61508-7 is a good starting point for things to consider for inclusion in a coding standard designed for development of safety critical functionality. Some examples of topics that should be considered for inclusion in a coding standard in addition to what is covered by MISRA rules: • How to guard accesses to shared resources, like global variables. • Use of stack and heap memory for object allocation. • Recursion, allowed or forbidden? • Complexity limits, like limits to the allowed cyclomatic complexity of functions. • How to waive e.g. MISRA rules that are not applicable in a certain context.

C C with subset and coding standard, and use of static analysis tools

R HR

– HR

NR HR

NR HR


TECH ARTICLES

C

• How to use compiler specific functionality, like intrinsic functions or language extensions. • How to use range checking, assertions and pre- and post-conditions and similar constructs to catch errors. • Interface organization and access between modules. • Documentation requirements. In essence, a coding standard should among other things give advice on how to deal with issues that affect code quality and integrity but are not explicitly addressed by the language or the language subset.

5. Practice makes perfect

In the following we will touch some topics arising from the previous section and how you can approach them in your project. 5.1 MISRA

If you plan to use MISRA, or are required to do so by external requirements or project stake holders, the approach can be slightly different depending on if you start out with a clean slate or if you are reusing legacy code. For newly developed code it can be worth considering the following advice: •D on’t go out of your way to blindly support each and every rule! For some parts of your code there is a very high probability that you cannot comply with one or more rules. This is especially true for code that interfaces to hardware. Instead, make an informed decision to deviate from the rule and document the decision. Discuss up-front with project stake holders and your external assessor if you have one, if you should aim to support all rules or if there are rules that can be ignored on a project level. To help you on your way the MISRA C:2004 rule set is already divided into a required part and an advisory part.

• At all times, strive to be compliant with rules that deal with the basic types, and arithmetic and conversion on such types! This is an area that is riddled with pitfalls and where code can seem to function perfectly on one platform, but break down on another. You might of course find yourself in a situation where you cannot comply, but then use your deviation procedure, document it and move on.

• If you find yourself using your deviation procedure for the same rule over and over on similar pieces of code you should consider it as a warning signal:

o Are you interpreting the rule correctly? o Is the code pattern really needed? o If it is really the only way to get the job done without complicating the implementation you should consider factoring out the offending code as an isolated function or set of functions.

• Use some form of static checker that can check your compliance interactively during development and preferably during integration builds etc. If you are applying a set of MISRA rules to legacy code it can be beneficial to:

• Work one rule at a time. • Select easy rules first, like the rule to embrace also single statements forming the body of a conditional construct with ‘{‘ and ‘}’. (MISRA C:2004 rule 14.8) • Look carefully at the rules stating that plain types like short, int and char should not be used and consider changing one module at a time to use explicitly sized types like uint16_t or similar. • In general, after practicing a bit on some easy modules, start off with modules that are considered to be buggy or difficult to maintain. 5.2 Synchronize it!

We will now change focus to one of the more widely misunderstood areas of the C language, namely the volatile keyword. No matter who you ask, misuse of the volatile keyword will go very high on the list of things that make embedded systems crash and burn. And incidentally, no matter whom you ask the probability is very high that you will get a slightly incorrect answer on how volatile works. The main reason to declare an object as volatile is to inform the compiler that the value of the object can change in ways unknown to the compiler and thus the compiler must preserve all accesses to a volatile object. There are three typical scenarios leading up to the need for volatile objects:

• Shared access; the object is shared between several tasks in a multitasking environment or is accessed both from a single thread of execution and one or more interrupt service routines. • Trigger access; as for a memory-mapped hardware device where the fact that an access occurs has an effect on the device • Modified access; where the contents of the object can change in ways not known to the compiler

25


C So, what kind of guarantees do you get from the compiler if you apply the volatile keyword to an object declaration? Well, essentially you get the following: • All read and write accesses are preserved. That’s it!

Depending on the target architecture you might also get:

• All accesses are complete, that is, the whole object is accessed • All accesses are performed in the same order as given in the abstract machine • All accesses are atomic, that is, they cannot be interrupted. • Only if the object is of a type that can be read/written atomically. Is the following code thread safe and interrupt safe, given that the volatile object can be accessed from different execution contexts? volatile int32_t vol = 1; void f5() { vol++; /* Is this atomic? */ }

This is how this code compiles for an ARM/ THUMB target: LDR.N LDR ADDS STR BX

R0,??DataTable7 ;;vol address R1,[R0, #+0] ;; Atomic R1,R1,#+1 R1,[R0, #+0] LR

;; Atomic ;; return

As can be seen both the load from memory and the store to memory of the value of vol are atomic since this is for a 32-bit load/store architecture. But the source statement is not atomic! We can still be hit by a context switch or interrupt somewhere in between the three instructions making up the vol++ statement. The volatile keyword makes sure that the load and store instructions are not optimized away and that their order is preserved and nothing else.

26

How to cope

• Never assume that volatile means atomic except for certain memory accesses! • Make sure code that does more than just an atomic read or write to a volatile object is guarded by proper serialization primitives if the object can be accessed from different execution contexts. (Locks, Mutexes, interrupt disabling or similar) • Cover the proper usage of the volatile keyword and serialization primitives in your coding standard. • Consider reviewing usage of all global objects, including file-scoped static objects in existing code.

5.3 Stacking up?

Is your stack small enough? Or big enough? This is a perpetual conundrum for developers; if the stack is chosen to be unnecessarily big it might mean a part with more on-board RAM has to be used which drives unit cost, but if on the other hand the stack is chosen too small we might go down in flames -And for a product under safety critical requirements that is not a good idea at all, to say the least. What can we do to ensure and confirm for ourselves and project stake holders that our stack size is at least as big as it has to be? Here is a checklist of possible actions to consider: • Use the run-time stack check functionality of your debugger, if such functionality is available. • Fill memory above and/or below the stack with a magic pattern that can be checked periodically in runtime by a dedicated check routine. This checker can be run by a watch dog interrupt for example. Check with your MCU supplier – Due to requirements in the IEC 60730 standard for household appliances they might already have this functionality and other MCU self-check functions available in a special purpose library. Consider reusing the stack-check functionality in all your projects.


TECH ARTICLES

• Perform a call tree analysis to determine worst case stack depth, including stack used by interrupt handlers. o By hand: Review code and examine linker map files. Remember that optimizations will affect stack usage and stack pressure can go both up and down as a result. o Buy or develop tool support. Create a script that identify call chains and count push/pop instructions on the assembly level. Or make sure you are using a build tool chain that can assist in the call tree analysis and stack depth analysis.

6. Spin me round We will round off this article with some examples of code that might or might not work as intended. 6.1 Global indexing? Take a look at the following code: int index = 0; /* Use global to save stack? */ void f4(int c) { for (index = 0; index < c; ++index) { a[index] += b[index]; } } Here the intention is to save a bit on stack space by re-using one global variable for different independent loops with the hope that the compiler can save a register by manipulating the variable directly in memory. This idiom has probably gone a bit out of fashion lately, but you still see it from time to time. The question is – does it work? Well, first of all the semantics of the language mandates that since the loop variable is global the value of the

variable after exiting the loop must be valid, even if the value of the variable is not used in the loop body except for counting up or down. This means that a number of loop optimizations and general optimizations will be prevented; which will probably lead to larger and slower code. And on a RISC architecture a register will most likely be used anyway for the loop counter arithmetic. For example: A typical loop optimization is to reverse the loop count to count down to zero if it can be done without changing the meaning of the program. This gives the possibility to use a decrement and test instruction if it happens to be available on the target, thus saving both some code size and probably speed. In this case it cannot be used because it changes the meaning of the program quite dramatically. Avoid global index variables! 6.2 Are all operators created equal? Here is the same code snippet again, but with a small but important difference – can you spot the difference? void f0(unsigned int c) { unsigned int i; for (i = 0; i <= c; ++i) { a[i] = b[i]; } } The difference is that the ‘<’ operator is changed to ‘<=’. Is there a problem with this code? What happens if the function parameter c is equal to UINT_MAX? According to the language semantics the loop will wrap around creating an infinite loop. But if you know that c will never take on that value? The code will work as intended, but the compiler must assume that c can take on that value and once again the result is less optimization which leads to larger and/or slower code. Avoid using ‘<=’ in loop tests!

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 27


6.3 In character MISRA C:2004 rule number 6.1 states that The plain char type shall be used only for the storage and use of character values. Why is that? One reason is that the signedness of the char type is implementation defined which in turn can lead to surprises if the type is used for non-character data. Look at the following classic example: void f1(char c1) { if (c1 == ~0x80) /* This might be a pointless integer comparison! */ ; } The problem here is that the result of the comparison will be completely different depending on if the char type is considered signed or unsigned for the platform we are compiling for. If the char type is unsigned the constant 0x80 will be converted to a 32-bit value and then bit-negated to a value that is always larger than the value of the unsigned char c1. Follow the MISRA rule and avoid using plain char for anything other than character values. 6.4 Double the fun

7. Take it away! To sum up this very long article we can summarize it in only 5 brief bullets: • Use MISRA C as basis for a coding standard • Review your usage of volatile • Implement a test and analysis strategy for stack allocation • Don’t be too clever in your code • Be careful with the char type

About IAR Systems IAR Systems is the world’s leading independent vendor of development tools for embedded systems. The highly optimizing C/C++ compiler and debugger tool suite IAR Embedded Workbench is available for 8-, 16-, and 32bit microcontrollers from all major vendors, including all ARM cores. Functional safety versions of the tool suite are available for ARM and for Renesas RX and are certified by TÜV SÜD according to the requirements of IEC 61508, the international umbrella standard for functional safety, as well as ISO 26262, which is used for automotive safety-related systems. With the certified tools, IAR Systems provides a Functional Safety Support and Update Agreement with guaranteed support for the sold version for the longevity of the contract. In addition to prioritized technical support, the agreement includes access to validated service packs and regular reports of known deviations and problems.

C

MISRA C 2004 rule 8.5 states that there shall be no definitions of objects or functions in a header file. If your header file has any similarity to the following you might be in trouble:

In file “foo.h” int global; /* Notice the missing ‘extern’! Creates a definition for each inclusion! */ In C this creates a definition of an object called global for each inclusion of the header file. The problem is that different tool chains and linkers can treat this differently. You might get a linker error or warning for multiple objects with the same name or you might get multiple copies silently treated as having file scope, i.e. treated as declared with the static keyword. Or you might actually get one copy, or rather several overlapping copies so the

28

code works as intended. Avoid definitions of objects and functions in header files unless you have very good reasons to do so!

For more information, please visit www.iar.com/safety

Follow IAR Systems on Facebook at www.facebook.com/iarsystems Follow IAR Systems on Twitter at www.twitter.com/iarsystems


C

TECH ARTICLES


IAR Embedded Workbench Empowers Developers With Functional Safety Certificati

30


TECH ARTICLES

ion Functional safety is one of the most important features in many embedded systems today. As today’s developers are encountering increased product complexity, they are looking for ways to help the development process become easier—including the time it takes for a product to achieve industry certification. IAR Systems acknowledges the industry trend of increasing complexity, which is why IAR Embedded Workbench comes with relevant industry certification. Now, developers can access a development environment to help easily certify their tools, changing their starting point from achieving certification, to start-and-go.

31


Functional Safety Tools for Renesas RX IAR Systems provides a toolset for developing safety related applications using the Renesas RX family of MCUs. The software is a complete development tool suite including the IAR C/C++ Compiler, assembler, librarian, linker, text editor, project manager, and C-SPY Debugger. Additional Features: • Extensive support for RX devices • Renesas RX ABI Compliant • Elaborated compliance with language standards • Integration with Subversion and other source code control systems • Integrated MISRA-C rule checker

32

IAR Embedded Workbench IAR Embedded Workbench is a development environment that helps the user generate faster code than ever before. The software incorporates a compiler, assembler, linker, and debugger into one integrated development environment, offering the user an all-in-one solution that provides a seamless development workflow. IAR Systems guarantees a powerful, userfriendly, and reliable product that enables the user to develop new competitive products with no tool qualification time necessary. With the certified versions of the tools, an exhaustive functional safety support and update agreement is offered. Standards and Certification Embedded applications used for safety critical functionality needs to fulfill certain requirements and be certified by an independent agency according to the relevant industry standard. Common standards are IEC 61508, the international umbrella standard for functional safety, and ISO 26262, which is used for automotive safety-related systems. High-integrity standards frequently require you to provide extensive justification for selecting a particular development tool. The proof of compliance for the tools increases cost and time of development, unless the tool is already certified.


TECH ARTICLES

Functional Safety Tools for ARM IAR Systems provides a reliable set of tools for developing safety-related applications, based on its C/C++ compiler and debugger tool suite for ARM. The program offers, advanced, multiple-level, global and target-specific optimizations on code size and execution speed allowing developers to generate code faster than ever before. Additional Features: • Extensive support for devices based on all ARM cores, from all major vendors • Elaborated compliance with language standards • ARM EABI and ARM CMSIS compliant • Integrated MISRA-C rule checker • Advanced inline assembler • Built-in RTOS plugins for Micrium, Express Logic, Sciopta, etc. • Integration with Subversion and other source code control systems

33


Buy vs. Build Part 1: Advantages of a Modular Design by Wolfgang Heinz-Fischer Head of Marketing & PR, TQ-Group

Embedded modules, sometimes referred to as Computer-on-Modules (COMs), or System-on-Modules, (SOMs), are the building blocks of the embedded world. Using modules alleviates many of the challenges facing engineers and project managers when designing complex applications. Some of the obstacles and costs associated with designing complex computing platforms--certification, design and development time and production costs--can be overcome by using an off-the-shelf embedded module. The following article examines some of these challenges and details how and where savings can be realized by opting for buying a pre-tested module instead of building a system from the ground up.

34


TECH ARTICLES Saving money, minimizing risks and bringing a product to market faster are often at odds with reality. Technology is becoming more complex. It requires longer development times, and therefore more development resources, greater design risks and higher development costs. At the same time, however, development resources are being reduced or more and more employees are shifted to the software sector. The software part of a product makes up an ever growing share and often actually represents the core competency of the user or of the application. This situation is compounded by the fact that a product’s 10 to 15 year life cycle has decreased to 5 to 8 years today, which means more products have to be developed or revised in a shorter period of time. In addition, it is becoming increasingly important to bring a product to market in a timely manner which, in reality, can only be achieved by using a modular design. The community of x86 users has relied almost exclusively on modules or standard boards for many years; integration is the absolute exception here.

Selecting Modular over Integrated Designs The concern that a modular design is more expensive than an integrated design is usually unfounded or based on an incorrect understanding of modular design. When can a modular design be recommended, or when is it the only way to develop a product?

Saving money, minimizing risks and bringing a product to market faster are often at odds with reality. Whenever in-house technical expertise or bandwidth is a reality (especially in the case of highly complex designs) , the modular approach might be the easiest and most economical way to solve this problem--apart from outsourcing the project entirely. A modular design can also help deliver the product on-time even with resource bottlenecks.

Hardware and Software Time Savings Add Up A look at the individual steps in the design process quickly shows where a modular design is advantageous. The time saved using a modular design is of course essential - after all, the processor module is already completed and has already been tested and, as a result, a crucial component of the hardware design is already available before starting the project. This makes it easier to design the application board and it can accordingly be developed more quickly.

35


Saving Money in Circuit Board Design As a rule, the circuit board is another significant cost factor. In this respect, it should be taken into account that the circuit board configuration is always determined by the most complex switching element or structural element. For example, a Freescale速 QorIQTM processor with a speed of 1.2 GHz and a DDR3 memory requires a multilayer structure with microvia and at least 10 or 12 layers. In a modular design, the application or carrier board can usually be implemented more easily with 2 to 4 layers less due to a lower level of complexity. Assessing the costs of the additional plug in a modular design compared to an integrated design from this aspect alone, one can quickly calculate that costs can be reduced here as well, or that no additional material expenses are incurred.

Circuit Board Math

Key software drivers are delivered with the module and can be used immediately so software development can start on day one. Some parts of the circuit can be deduced from the reference design in the starter k it, which allows the application board to be designed even more quickly and reliably. Time can be saved on the software side as well. The key software drivers are delivered with the module already and can be used immediately-so software development can start on day one since the target platform is already available. Therefore, real parallel engineering can take place. Performance tests are often necessary before a final design decision is made. This, too, can usually be conducted with modules, further reducing development time.

36

The average price for a circuit board measuring 6.9 inches x 4.7 inches (175 mm x 120 mm) with 12 layers is about $30 for medium quantities. Using a module allows the multilayer structure to be reduced to eight or less layers. The circuit board price for eight layers is about $21 to $23 for the same quantities. A set of mating connectors for a TQ module with QorIQ processor is about $7 to $9 per unit; consequently, no additional material expenses are incurred by using a module. A less complex application board certainly presents a lower risk for a necessary redesign than a highly complex board. This creates not only additional costs but also a time delay-which can incur more costs. In terms of long-term availability, storage devices are the most critical components in a processor application today. For a product, this means that redesign will probably become necessary in the course of the life cycle due to discontinued memory modules. If modules are used, this is the responsibility of the module producer, hence further cost savings in the entire life cycle of a product.


TECH ARTICLES Interest on Investments

A Design Calculator

If overall development costs decrease, the interest paid on these investments will be accordingly lower as well. If one expects to achieve cost savings of up to $135,000 in development, an interest rate as low as five percent means additional costs of $6,750 per year.

By choosing an example with concrete figures and closely examining the individual steps from idea to end-of-life of a product, you can determine the advantages of a modular design or discover up to what quantity modular design is an advantage in a given case. The example presented on these pages uses a Freescale i.MX6 processor for comparison.

Since the module will be used by many customers, each customer will benefit from the excess quantity produced by the module provider. And using a module in other products, that is, at higher quantities, results in additional room to negotiate a price. In addition to pure development costs, continued investments for the acquisition of the appropriate tools for development, manufacture and test equipment may be required.

Risk Minimization Another crucial factor affecting developments today is risk minimization. Risk means time and costs. Since the design for the application board is much simpler in a modular design, the risk of eventual redesign is significantly lower. A redesign in the course of the life cycle usually becomes necessary for the embedded module only because this is where the memory modules are located. Less risk and timely completion of development can play a crucial role in contributing to a product’s commercial success. What developers to realize more and more ambitious designs--one more reason to use a modular design.

The Concept Phase

TQ embedded modules:

In the concept phase, analysis of the components to be used, determination of long-term availability, DfX (Design for X) concept, feasibility studies, and time and personnel requirements come to approximately $70,000 for an average design with an i.MX6 processor. With a modular design – the design of an application board – $27,000 is generally enough to budget for the concept phase. Preparing a Circuit Diagram Preparing a circuit diagram for an application board costs about $6,500, especially if you can draw on existing tested circuit plans from the starter kit. When the processor is integrated, the circuit diagram becomes considerably more complex and usually costs approximately $25,000 to $30,000.

In terms of long-term availability, storage devices are the most critical components in a processor application today. For a product, this means that redesign will probably become necessary in the course of the life cycle due to discontinued memory modules.

A TQMa6x module with a Freescale i.MX6 can save you design time and money

Are the smallest in the industry, without compromising quality and reliability

Bring out all the processor signals to the Tyco connectors

Can reduce development time by as much as 12 months

The TQMa6x module comes with a Freescale i.MX6 (ARM® Cortex™-A9), and supports Linux operating systems. The full-function STKa6Q-AA Starter Kit is an easy and inexpensive way to evaluate and test the TQMa6x module.

To order a Starter Kit or for more information, please visit www.TQ-USA.com

TQ-USA is the brand for a module product line represented in N. America by Convergence Promotions, LLC

Technology in Quality

TQMa6x 1/3 Page Ad.indd 1

37

10/25/13 5


Testing and Testing Equipment The production costs themselves do not differ very much, but the case is very different for testing costs. As a rule, integrated designs require more complex testing equipment, and costs amount to $60,000. Providing for Continued Product Availability One of the leading factors in deciding to go with an integrated design or a module is the question--if you go with an integrated design, will your components still be available ten years from now?

Additional costs of total development and product qualification can quickly run up to $250,000 to $300,000 for an integrated design. The Layout The differences are even more obvious when it comes to the layout. Since the application board is clearly simpler to put together with a modular design, $13,500 to $15,000 will usually suffice. With integration, however, costs can easily double. Prototype Creation For creation of prototypes, the values for modular and integrated designs are usually not very different. However, differences can be considerable here if new equipment needs to be procured. Paying for Drivers in an Integrated Design The module is delivered by the manufacturer with certain drivers and BSPs included. If the drivers for an integrated design need to be created for the design itself, add a price tag of at least $50,000. Controlling BOM Costs BOM costs are reduced by the costs of the parts in the module and a more affordable circuit board, but are increased by the costs of additional connectors.

38

Certification What is it going to take to get certification for a medical (DIN EN ISO 13485) or aviation (EN ISO 9001)? Buying a module that is already certified will save a lot of time and money in the development process.

The Bottom Line The examples in this article demonstrate that additional costs of development and product qualification can quickly become $250,000 to $300,000 for an integrated design--not counting the costs of additional risks of re-designs in the course of the product lifecycle, varying quantities for product planning, and interest charges. The break-even point after which an integrated version appears to become more affordable can be calculated very quickly. Once you’ve decided that going with a module instead of an integrated design is the right approach, then you can begin searching for the right supplier and the modules to meet your needs. Good Luck. Need help in making a decision? TQ-USA can be found at: www.convergencepromotions.com/TQUSA/


TECH ARTICLES

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

39


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

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

Clean Energy

Let There Be

LIGHT

FUTURE

How Cree reinvented the light bulb

— Hugo van Nispen, COO of DNV KEMA

Cutting Edge

SPICE

Modeling

MCU Wars 32-bit MCU Comparison

+

Cutting Edge Flatscreen Technologies

+

New LED Filament Tower

View more EEWeb magazines— Click Here

Power Developer O ct o b er

201 3

From Concept to

Reality

Sierra Circuits:

Designing for

Durability

A Complete PCB Resource

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

TQ-Group’s Comprehensive Design Process

Freescale and TI Embedded Modules

+

Ken Bahl CEO of Sierra Circuits

PLUS: The “ Ground ” Myth in Printed Circuits

+

+

PCB Resin Reactor

ARM Cortex Programming

Low-Power Design Techniques


Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.