As the market for embedded systems grows dramatically, all eyes are turning to embedded systems designers who are tasked with combining microprocessors, connectivity, and operating systems that span a wide range of applications from the tiniest IoT device to those embedded in large networking systems.
According to IDC, the market for intelligent systems will grow from 1.4 billion units this year to more than 2.2 billion in 2019. While marketers and financiers may be salivating over the prospects for revenue, what does this really mean for the embedded system designer? From my armchair view, I could easily guess that these challenges likely center on the perennial challenges that electrical engineering designs face: size, cost, power, and time to market. I recently asked Chris Shore, training manager for ARM, and Shawn Prestridge, senior field application engineer at IAR Systems, Inc. about just this subject. Both Shore and Prestridge are members of the ARM TechCon Technical Program Committee (TPC), and will be speaking on these topics at next week’s ARM TechCon Conference in Santa Clara.
The biggest design concerns Shore sees are “getting to grips with multicore platforms, implementing secure systems in IoT, resilient and reliable programming, and energy efficient development.” To be sure, these are topics that are regularly addressed in embedded trade journals and conferences. Considering the entire development cycle, Prestridge points to shortened time to market versus increased design functionality as a critical challenge. This is a common pain point in a market that is getting “hot” with many new players entering the space.
Prestridge says that a key bottleneck is that many of the boards available today can only get designers about “half way to the functionality they need.” So, they need to complete the rest of the design using other available hardware and software. Then, engineers have to enter a rigorous testing cycle to ensure that everything works well under stress and that the integration with the hardware and software they’ve added is as defect-free as possible. He notes that using “reference designs as well as trusted tools with smart features for designing, debugging and code analysis give you the shortest time-to-market even as the complexity of your design increases.”
But what about energy efficiency? It’s not just engineers who are working on battery operated devices that are being tasked like never before to reduce power consumption and look for creative power sourcing options. Prestridge notes that over the last 10 years, the green engineering movement has caused all teams to be concerned about their products carbon footprint, regardless of whether they will be battery operated or plugged in to the wall. “The green engineering movement has made engineers consider how to get the most out of every electron they use and the market has responded by making it easy to get low-power variants of popular devices,” he adds. Also, Prestridge observes that it is easier to determine your design’s power profile because of new debugging tools that tie energy consumption to the source code, “so making the designs energy efficient is now the responsibility of both the hardware and software engineers.”
Shore concurs that the energy efficiency needs to be achieved by both the software and hardware. He notes that work needs to be done writing genuinely energy efficient software, saying that “Tools are emerging which support this, but the industry has much to learn here.”
One of the classic trade-offs is between power and performance. How is this being addressed in embedded design? Shore offers some tips:
- carefully architect software to take advantage of the facilities provided by the hardware
- ensure that you understand exactly what the hardware is doing at all times
- have a deep knowledge of power saving facilities provided by your platform
- design your software (from algorithms down to machine code) carefully and conscientiously
- design interrupt handlers carefully
Prestridge says that his company, IAR Systems, has done quite a bit of research into helping developers achieve the best possible combination of power and performance. He suggests that from the software side, a good approach is to optimize code for speed so you can quickly put your microcontroller into a low-power state. (He notes that many commercial RTOSs already leverage this in their products.) However, if the application is constantly processing data, he suggests you find the minimum clock frequency of your microcontroller that still allows you to get the throughput you need. (This approach also demands that you optimize your code for speed, which will allow you realize the lowest possible clock frequency.)
You cannot seem to have a conversation about the IoT these days without discussing security or the latest automobile hack. Shore notes that the challenges of security in the IoT need to be met not only in hardware and architecture, but also in software design. As time goes on, “security is only going to become more important for us,” adds Shore.
Prestridge notes that (despite the noteworthy hacks lately) the automotive industry has been working on security for years, as has the medical and aerospace industry. It is only relatively recently that security has become a concern for commercial and durable goods. Prestridge outlines the challenge: “Functional safety-certified tools aren’t enough; code analysis tools (both static and runtime) can help ferret out potential security issues by spotting things like the classic buffer overrun exploit before the design gets in the field. By using code analysis tools, developers can prevent these problems before they ever get checked into a build. And by selecting a pre-certified tool that has already been quality-tested by an independent third-party organization specialized on safety requirements, entire companies can save valuable time and money.”
Shore offers some parting advice: “Modern embedded systems are now, in many cases, as complex as the desktop systems of 5 years ago. The embedded developer needs to understand and utilize design and coding techniques that were the exclusive province of the desktop community only a few years ago. There is only so far that the tools can take you in this and developers have a huge task to educate themselves about things like superscalar processors, out-of-order memory, caches, multicore platforms etc.”
Prestridge suggests that a great way forward is to look at a prospective vendor/partner’s example projects, because they can be critical to getting a head start on application development. He also says it helps to add functionality to software one code block at a time, making it easier to identify where faults lie. “This is why it’s critical to use a toolchain that partners with as many semiconductor partners as possible so that you have the widest and deepest well of examples from which to draw. You have the best chance of meeting your project’s schedule when you can draw from a large repository of dependable code and have an equally reliable toolchain to debug your application.”
You can catch Shore and Prestridge at ARM TechCon 2015 in Santa Clara, CA as well as many other speakers sharing their expertise on ARM-based embedded systems design.