Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Advances in embedded SW design re-use and IDEs

Posted: 14 Nov 2012 ?? ?Print Version ?Bookmark and Share

Keywords:Integrated development environments? Microcontroller? application programming interfaces?

As the processing capability of embedded systems increases, design software plays an increasingly significant role in the productivity of the design engineer and, ultimately, the success of the end product. When a design engineer has effective development tools at his disposal and can easily reuse previously developed software C even if developed on different processor architectures- he/she is well-positioned to achieve faster time to market. Integrated development environments (IDEs) have evolved to include productivity-enhancing resources such as software frameworks that minimise much of the low-level coding in a design, freeing the engineer to focus on design differentiation.

Addressing design complexity
Microcontroller (MCU) vendors have continued integrating more functions into their platforms, bringing greater complexity to the design process. Additionally, moving to a new MCU could require downloading new support code archives and documentation, and learning new application programming interfaces (APIs). At the same time, the market environment demands rapid scaling as well as the ability to tune offerings to react swiftly to changing market requirements. Faced with these pressures, embedded developers are realising that increasing their code reuse is the most pragmatic way to achieve higher levels of productivity. Embedded development teams can now find their solution in a comprehensive platform-independent software framework.

An example of this approach is the Atmel Software Framework (ASF), which is integrated into the new Atmel Studio 6 IDE. The ASF facilitates a top-down design approach to embedded systems development that leverages the accumulated IP and experience of the organisation by avoiding the requirement to rewrite significant portions of the code for each port to a different MCU variant or architecture.

Design portability across different MCUs
ASF has been architected from the ground-up to provide a clean interface between user application code and the software stacks that enable the application to run on a variety of different embedded target MCUs. The production-ready ASF provides everything required between the application and the hardware design. The functions and code examples that use them are all optimised for code size for each target architecture and work with a range of ANSI-C compilers. The ASF code is also architecture-optimised by Atmel experts. The functions take full advantage of Atmel MCU features such as low-power modes and the Peripheral Event System.

Chip-specific features in the protocol stacks and functions are used in a way that maximises portability for application-level code. But the functions are implemented using a common API that abstracts away the target-specific details, allowing developers to take code developed on one Atmel device and compile it for a new Atmel target, practically unchanged.

For example, the API uses an intuitive format in which devices are programmed using function calls that follow a consistent naming convention: _init(); _enable(); _disable(); _start(); _stop(); _read(); _write(); etc.

Efficiency in application code
ASF modules are arranged in a layered architecture that allows application code to call functions that are most appropriate to the task at hand. This architecture also makes it easy to add support for complex protocols, such as USB, to a product. There are four types of layers: component, service, peripheral and board.

The component and service modules are called directly by the application, unless it needs direct access to low-level device functions provided by the peripheral and board layers. The service layer provides the user with application-oriented software stacks such as USB class drivers, file systems, architecture-optimised digital signal processing functions and graphics libraries. This layer also takes advantage of the MCU's hardware features.

Components are high-level drivers that provide intuitive and direct control over MCU and board-level peripherals, such as display, sensors and wireless interfaces. The code in the component layer is written with a focus on providing the functionality that a typical user will need in each of the on-chip peripherals. If the application calls for a peripheral to operate in a way that is not directly supported by the component layer, it is easy for the user to modify the existing source code, or add an extra function to the API.

The component and service modules communicate with low-level drivers in the peripheral layer that provide register-level control over hardware interfaces. Applications can also call these drivers directly to facilitate tight hardware integration in a way that maximises portability between members of the Atmel MCU portfolio.

Other features
Finally, the board module provides the hardware view of the MCU in its target environment. The board code abstracts the modules above the board from the physical wiring and initialisation functions that take care of I/O and external devices. The board code also identifies which board features are available to the modules higher up in the software stack.

1???2?Next Page?Last Page

Article Comments - Advances in embedded SW design re-us...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top