Microcontrollers address and optimize application-specific tasks: Interview with Mike Copeland, Infineon Technologies
May 01, 2014
Application Specific Standard Products (ASSPs) control many basic functions of embedded systems, and work well when customization isn't necessary. Mic...
Application Specific Standard Products (ASSPs) control many basic functions of embedded systems, and work well when customization isn't necessary. Microcontrollers (MCUs) that are optimized for specific system applications can provide designers with more options for customization and differentiation. Embedded Computing Design spoke with Mike Copeland, System Applications Manager and Principal Engineer, Industrial Microcontrollers and Motor Control Systems, Infineon Technologies about the role of ASSPs and application-optimized MCUs in embedded computing. Edited excerpts follow.
Q: What is Infineon's take on the Application Specific Standard Product (ASSP) market? What applications are driving their use?
We do see widespread adoption of ASSPs in the power supply portion of many applications. In general, ASSPs are selected when the innovation in a project does not arise from the function provided by the ASSP. This may be in well-established product categories where the differentiation isn't in the chip-level feature set. In emerging product categories or existing categories that are evolving rapidly, the project team is more likely to look at an application-optimized Microcontroller (MCU), which lets designers add their own "secret sauce" in the software and hardware.
Q: How do ASSPs address the needs of embedded device design teams' goals? When are they most useful? When are they not useful?
In general, when the project implements a solution that is already well handled and that is "good enough" for the development team's goals, an ASSP makes sense.
ASSPs can jump-start a product design project, but the design team is limited to the fixed functionality of the device. While some ASSPs include an MCU or programmable elements, the available resources are typically limited or the full capabilities of the MCU are not exposed.
Markets with fewer "standards" tend to use application-optimized MCUs. This can include both high-volume and relatively small application segments where there is a lot of room for design innovation. For these areas, an application-optimized MCU such as the Infineon XMC family combines general-purpose or even application-specific features as peripherals on the same silicon die, and provides programming flexibility to add differentiation in the hardware/software design.
Looking at ASSPs and MCUs, the processor choice will vary even within a product category. For example, there are good ASSPs for straightforward power conversion or simple motor control systems. But if the design team is pushing the envelope for overall efficiency or control precision, then an optimized MCU offers the right combination of programmability, cost, and design time advantage.
Infineon designed its XMC application-optimized MCUs to address these limitations. Each device family is based on a different 32-bit core – the ARM Cortex-M4 for the XMC4000 and the ARM Cortex-M0 for the XMC1000 (Figure 1). Both product families are optimized for industrial applications, such as drives, factory automation systems, lighting control and renewable energy systems. Examples of this type of optimization include implementing a Pulse-Width Modulation (PWM) unit with resolution down to 150 picoseconds; the high accuracy helps improve efficiency in power applications. The peripheral set includes 12-bit resolution ADC modules, with up to four available on our higher-end devices, specialized math units, and timers. Another example is error correction in flash memory, which relates to safety issues in factory automation.
|
|
Equally important to the concept of application optimization is that we make these features very easy to program and give designers complete access to the MCU core and peripheral code.
Q: How does Infineon's programming model for application-optimized MCUs work to integrate peripherals that may be needed in one application's context, but not in another? Does it also allow peripherals/gates to be shut off if not needed?
We implement a flexible gating structure for all peripherals that can power down any component not used. You can set up the application to never power up portions of the chip, even during boot, which saves the kind of in-rush power drain at startup that's common to many systems.
The typical approach to application support is to offer sample code and libraries that a design team can plug in to its project. We decided that an ecosystem for application-optimized MCUs had to offer more, which led to a very powerful development environment called DAVE, or the Digital Application Virtual Engineer. It supports component-based programming where the developer configures and combines different elements – like ADC and PWM generation. The various hardware elements and software components – called DAVE Apps – are combined without touching the source code. The next step is to map the defined components to the XMC hardware. The tool suggests the specific chip resources to use and can even suggest the pinout. For example, it says that a specific analog to digital channel can use pin 12. When the developer is satisfied with the configuration, the environment automatically generates the C code for compilation in any tool chain.
With this approach it's much easier to combine and configure available components compared to editing the source code. Constrained logic handles potential device conflicts and greatly simplifies set up of the real-time peripherals. Development teams gain more control through a higher level of automation, but at any time a developer can dig down to the source code and tweak it to meet specific goals. An organization with deeply experienced programmers on a project can work at the source code level while others work at a higher level of abstraction.
Q: What are the prime examples of application-optimized MCUs over other comparable technologies? What is the best choice for high, medium, and low-volume deployments?
There is a spectrum of application processor solutions available to embedded designers. This includes ASICs, which offer high-level customization and are unique to a single OEM; ASSPs that offer a set of functionalities required by multiple OEMs; user-customizable FPGAs; and application-optimized MCU platforms. ASICs present the largest number of limitations, with well-understood cost and time to market restrictions. FPGAs are highly configurable, but cost and size can limit their use to lower volume applications.
Market volume is not the right measure when choosing between an ASSP or application-optimized MCU; both ap-proaches have large roles to play in a development organization's tool kit. It has more to do with the specific project goals and business strategy of the development organization.
A good example of this is motor control for a cooling fan application. Perfectly good ASSP solutions are available. But if there's a requirement for very high efficiency and super quiet operation, then a dedicated effort to implement optimized control, variable speeds, temperature sensitivity, and other fea-tures is best served with an MCU-based approach. Similar examples apply in lighting design, renewable energy, power supplies, and other market segments.
Infineon Technologies
www.infineon.com @Infineon www.linkedin.com/company/infineon-technologies www.facebook.com/InfineonAmericas www.youtube.com/user/InfineonTechnologies
