As system complexities rise and management and market pressures drive tight schedules, engineers find that meeting schedules and budgets are constantly top concerns. The innate, driving, subconscious force within engineers to develop the best, customised, top-of-the-line, latest and greatest widget exacerbates these challenges.
Balancing aggressive timelines and cutting-edge performance, as systems and devices grow in complexity, requires improved hardware and software tools combined with careful planning and engineering practices.
Engineers are finding value in improved tools that integrate the functionality of multiple previous tools. For example, when it came to designing new hardware, an EDA vendor recently improved its ECAD software by integrating mechanical CAD capabilities into the existing tool. This improved collaboration between mechanical and electronic design teams, and enabled designers to interactively ensure compatibility between their electronic component placement and clearances with their mechanical requirements and enclosures.
By integrating both areas of CAD into a single tool, this vendor improved the design process while decreasing the frustrations associated with maintaining and synchronising the mechanical and electrical portions of a device. While improving the CAD tools improves the design cycle for custom hardware, many engineers are eliminating the entire custom hardware design cycle and accelerating product development by using off-the-shelf single-board computer (SBC) hardware controllers and modular I/O peripherals.
Single-board solutions
Single-board computer hardware platforms traditionally favour convenience over customisation. Designers may discount single-board computer hardware as a viable solution because they assume they can design a lower-cost custom solution. While the cost of an SBC solution may be higher per delivered system than an optimised custom design, the overall cost savings of off-the-shelf devices are realised by shortening design time, reducing initial investment and minimising sustaining costs. An SBC platform cuts sustaining efforts because the SBC vendor assumes responsibility for adapting to new technologies and end-of-life components, identifies and corrects any design flaws, and provides update and migration paths to future devices.
To attempt to lower the deployment costs of an embedded device, many SBC hardware vendors are integrating a flexible combination of SBC controller, advanced I/O and peripherals to a generic platform. While a flexible SBC usually contains a superset of features implemented in a custom design, the piece price of these devices is driven down near the price of a custom in-house design by economy of scale in manufacturing efficiencies and an advantage in component price negotiation over a custom hardware design.
SBC hardware significantly accelerates the product design lifecycle, such that software development becomes the critical path in the development cycle. Although hardware components that are integrated onto a single PCB may save on hardware costs, the software integration of subsystems and peripherals is no easier on a highly integrated semicustom SBC than using a standard form factor plug-in board (see Figure 1).
Hardware providers in the embedded space traditionally offer a simple pre-loaded board support package (BSP) with support for a specific operating system (OS), with claims of support for a multitude of other OSs. The designer is responsible for all the layers of software support above the provided bootloader. Software developers lose valuable time while developing and testing low-level device drivers and language-specific driver APIs, before they can even begin application-level programming.
Application development
After the supporting software layers are complete, programmers can focus on solving the goals and challenges of their actual embedded device. Overall, the application feature development cycle is relatively short. Because all the supporting software layers of the application are new, developers must plan for ample application-level testing and driver-level verification. Debugging errors in various abstraction layers of the software are always a top concern of design engineers and a common reason why release schedules are delayed.
It might be assumed that a way to shorten the software side of the design process is to use off-the-shelf software components, similar to the approach recommended for accelerating hardware design. While commercial and open source components, such as operating systems and device drivers, will provide a good starting point, they must still be ported and validated on specific hardware. Porting and integrating those different software components requires diligent validation to ensure those components do not introduce bugs into top-level application software.
To address these challenges, designers need system-level design tools that tightly integrate pre-validated and hardened software middleware and application layers with a modular, feature-rich SBC hardware platform.
System design tools
Most embedded system vendors are focused on either hardware or software design. Few attempt to master hardware design, low-level driver development and high-level application software development tools. If a software vendor builds up advanced driver and application-level support for a given target, they usually only support a very specific hardware device, such as a processor evaluation kit, and use that target support as a demonstration and evaluation tool.
Graphical system design tools, such as National Instruments’ LabVIEW, are available to help designers address this challenge in embedded system design (see Figure 2). These tools have built-in support for a wide range of form factors, performance and price points, ranging from PXI and CompactPCI controllers and plug-in boards down to board-level standalone products such as the NI single-board RIO platform.
The same development environment and language can program multiple types of target platforms. While LabVIEW and other graphical system design tools are a high-level graphical programming language, they also provide interfaces for reusing code from previous projects written in traditional languages such as C/C++ for CPU-based systems and VHDL or Verilog for FPGAs. Using graphical system design does not force designers to abandon any existing code libraries and start over from scratch.
For more information contact National Instruments, 0800 203 199, [email protected], www.ni.com/southafrica
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version