2012 Mercedes-Benz ML350 Safety Features

The safety features found on the 2012 Mercedes Benz ML350 include the ability to avoid a rear end collision and detect if you're sleeping behind the wheel.

IAR Systems provides development tools for the new low-power V850E2 microcontrollers from Renesas Electronics

Uppsala, Sweden—March 16, 2012, IAR Systems® announces complete support for the V850E2/Fx4-L microcontroller series from Renesas Electronics.

The V850E2/Fx4-L series features very low power consumption paired with high functionality. It is designed for the automotive comfort and body segment, for applications such as roof or window lifters, HVAC (heating, ventilation, and air conditioning), body control modules, and door, seat and light modules. These new microcontrollers provide power-saving features such as the sequencer (SEQ).

 The SEQ supports hardware monitoring of digital inputs in deep stop mode without any usage of the CPU or memory. When the SEQ detects activities at the digital inputs, the device switches from deep stop mode to run mode. Another feature is the LIN-master controller (LMA) which supports the automatic LIN-frame detection without CPU interactivity.

The highly-optimizing C/C++ compiler and debugger tool suite IAR Embedded Workbench® for V850 supplies extensive support for all devices in the V850, V850E, V850ES, and V850E2 families. The V850E2/Fx4-L microcontrollers are supported by IAR Embedded Workbench for V850 version 3.81, available today. This new release also adds support for Reneas E20 emulator, integration with the version control system Subversion, and new license features, such as commuter licenses, automatic license activation and support for virtual servers.

IAR Embedded Workbench is available for a variety of Renesas targets, in total more than 4.000 devices.

 IAR Systems is the largest independent vendor of development tools for Renesas microcontrollers, and is committed to continue to deliver high-performing, user-friendly tools for all Renesas microcontrollers.

To read more about IAR Embedded Workbench for V850, and to download evaluation versions, go to www.iar.com/ewv850.

Mind-controlled skateboard

TI's new development kit helps engineers quickly and easily design Bluetooth® technology-enabled applications based on Stellaris® microcontrollers

Texas Instruments Incorporated (TI) (NYSE: TXN) today announced the Stellaris® 2.4 GHz CC2560 Bluetooth® Wireless Kit (DK-EM2-2560B), aimed at jumpstarting Bluetooth®-enabled designs. The kit includes the high-throughput, power-efficient CC2560 Bluetooth solution and proven Bluetooth stack within StellarisWare® software. The performance and integration of Stellaris MCUs pair with TI´s leading Bluetooth solution to help developers address the demand for more streaming audio, remote control and data transfer in industrial and consumer applications. For complete details, visit www.ti.com/bt-kit-2560b-pr-tf. For a video demonstration, visit www.ti.com/bt-kt-pr-v.

With this offering, TI further expands its broad portfolio of complete microcontroller and wireless technology solutions, which includes 16- and 32-bit MCUs backed by ZigBee®, low-power wireless, RFID, and Bluetooth hardware and software. The Stellaris 2.4 GHz CC2560 Bluetooth Wireless Kit is modular and can be combined with the same Stellaris DK-LM3S9B96 Development Kit that serves as a baseboard for other Stellaris wireless solutions. When coupled with the DK- LM3S9B96 development board, the kit includes all hardware and software needed to jumpstart development. It also speeds the design process, as engineers are able to evaluate the working Bluetooth solution within 10 minutes or less using the included quick-start application.

What’s included in the Stellaris 2.4 GHz CC2560 Bluetooth Wireless Kit

Software

·         StellarisWare® software, including peripheral driver library and example source code

·         Bluetopia® Bluetooth stack – developed by Stonestreet One and licensed, delivered and supported by TI – which includes the Serial Port Profile (SPP), Advanced Audio Distribution Profile (A2DP) and Audio Video Remote Control Profile (AVRCP) with sample applications

Hardware

·         Stellaris DK-LM3S9B96-EM2 Expansion Board

·         PAN1323 Bluetooth v2.1 + Enhanced Data Rate (EDR) Module

·         TI eZ430 USB emulator with Bluetooth target board and plastic cover

·         Battery board

·         Two AAA batteries

·         Earbud headphones

·         StellarisWare® CD

Features and benefits of the Stellaris 2.4 GHz CC2560 Bluetooth Wireless Kit

Features

Benefits

Bluetooth 2.1 technology + EDR support

Best-in-class Bluetooth RF performance for robust, high-throughput wireless connection, extended range and better power efficiency

Complete, validated, certified, production-ready module (PAN1323 used for evaluation, PAN1315 or PAN1325 used for production)

Lower manufacturing and operating costs, save board space, ease certification, minimize RF expertise required

Sample applications for the Stellaris LM3S9000 series, with demos showing API usage provided in source code

Simplifies and reduces hardware and software development, allowing faster time-to-market

Price and availability

The Stellaris 2.4 GHz CC2560 Bluetooth Wireless Kit (DK-EM2-2560B) is priced at $199 US, and available to order today at www.ti.com/bt-kit-2560b-pr-es. The DK-LM3S9B96 is sold separately for $425 U.S., and available to order today at www.ti.com/bt-kit-9b96-pr-es.

Fundamentals Of Low-Power Design

In the realm of design, the quest for low power continues ad infinitum as a primary goal. Yet low-power requirements place significant additional constraints on designs, constraints that ordinarily would be secondary or non-existent. Often, a simple oversight in the firmware executing on a part can substantially reduce battery life.

When on this quest, designers must ask—before writing any code, selecting components, or creating schematics—what “low power” means. Almost always, the answer is that it depends. For instance, it depends on the application, the typical use case, and a whole slew of tradeoffs involving cost, performance, size, and other factors.

Classifying Devices With Regards To Power
Classes of devices with vastly different power needs and power consumption profiles typically include:

• Rechargeable, battery-operated handheld devices: These devices, which often have a runtime measured in hours, are designed to be frequently recharged. They perform little or no processing when off, but significant processing when running. Portable media players and cellular phones fall into this category.

• Devices that spend most of their time in sleep/standby: Such devices have runtimes measured in weeks or months. There’s very little processing when the device is on, and it returns to sleep mode quickly. Most of the time, the device is in deep sleep or standby. These devices include IR/RF remote controls, portable test equipment, wireless keyboards, and blood-glucose meters.

• Devices that are barely alive: Runtimes for these devices are measured in months or years. Minutes, hours, or even days can elapse between short bursts of activity. They’re often found in remote monitoring applications. Utility metering and data loggers are two examples.

Means Of Measurement
So, how do you identify a low-power device? Once again, it depends. There are many ways to define and measure power consumption. Any datasheet, product brief, or application note for a low-power microcontroller comes replete with a colorful assortment of specifications. Common specs include MIPS/watt, mA/MHz, low-power run-mode current consumption, and sleep-mode current consumption.

No single specification tells the whole story, and the actual performance depends heavily on the use case. For instance, a device with a great mA/MHz specification might have an unacceptable sleep-mode current. What’s more, the functionality in each of these sleep modes may not even be easy to quantify. Does the part have any timers active in the mode of interest? Does it keep the contents of RAM? Comparing apples to apples here is an effort unto itself.

Power-Saving Techniques
Despite the myriad product specifications, requirements, and design constraints, much can still be done in any design to minimize power consumption. The following standard techniques can help save power on most modern microcontrollers and processors:

Eliminating Parasitic Peripherals
Since many microcontrollers come out of reset with peripherals enabled, disabling unused peripherals will save a significant amount of power. Often, this is simply a matter of clock gating; turning off the clock to a peripheral will completely eliminate its power consumption. In some situations, though, a more sinister power sink lurks in the bowels of peripherals, a.k.a., quiescent current.

In applications that demand deep sleep and maximize every nanoampere, the peripherals’ quiescent-current consumption becomes vital. Analog peripherals such as comparators and analog-to-digital converters (ADCs) are good examples where clock gating alone won’t suffice when powering down the peripheral.

1. This excerpt from Freescale’s MC9S08QE32 datasheet for the analog comparator peripheral illustrates how leaving the comparator on isn’t a good idea.

The specs shown in Figure 1 were lifted from datasheets for Freescale’s Flexis QE series low-power microcontrollers. On the Flexis QE32, the comparator’s power consumption falls in the 20- to 30-µA range. This may not seem like a lot, but considering that the deepest power-down current consumption on the device measures 350 nA (at V_DD = 3 V), leaving that comparator on isn’t a viable option.

Configuring Unused I/O
Unused I/O can be a major source of unwanted power consumption if it’s left configured as an input. In standard CMOS logic, power consumption occurs only when switching states from on to off and vice versa. Floating inputs will cause unintentional switching. The best way to handle unused I/O is to set it as an output when power must be saved, i.e., in a power-down or low-power run mode.

From a board-level perspective, it’s important to consider the lowest power state of the circuit connected to the pin. For example, if the pin is pulled up or down externally, set the output to the value corresponding to V_DD or ground, respectively.

Remember, in this scenario unused I/O isn’t limited to the I/O that’s never used. Any time a peripheral or a set of I/O isn’t necessary, it can be reconfigured as an output on-the-fly. This is generally a good idea when entering a low-power mode of operation that works with limited functionality. Dedicated analog inputs must be treated carefully at the board level, as they can be input-only pins with input impedances in the tens of kilohms.

Run-Mode Clock Throttling
In applications featuring a device operating in active mode, where the CPU is enabled and processing for extended periods of time, it makes sense to carefully evaluate the performance/power tradeoff. For instance, low-power applications rarely require blazing-fast speed. Usually, the CPU performs some rudimentary calculations on data or manages peripheral interaction with the outside world.

2. This excerpt from Texas Instruments’ MSP430F2132 datasheet lists the run-mode current for various CPU clock frequencies.

At times, the CPU needs to be on, but its role is limited. Here, lots of power can be saved by throttling its clock down to a level where it efficiently processes data without becoming idle. An excerpt from the Texas Instruments MSP430F2132 microcontroller datasheet illustrates this point, listing the active-mode current consumption at various CPU clock frequencies (Fig. 2).

Taking Advantage of Bursty Operation
On the other side of the CPU throttling coin, bursty operation for processing and data acquisition offers another good opportunity to save power. The principle behind this technique involves minimizing the time in an active mode of operation. It may be unintuitive, but performing the tasks that consume lots of static current for a shorter period of time can be more power-efficient than doing so for a longer period of time at lower power. This applies equally well to CPU run modes and high-power peripherals such as ADCs.

3. Shown is the active-mode current consumption versus processing time for two hypothetical microcontrollers: an eight-bit CPU (a) and a 32-bit device (b).

The burst-mode principle for processing data can be elucidated further by comparing power consumption between 8-bit and 32-bit hypothetical devices (Fig. 3). Both wake up with the same periodicity to acquire and process data. Because the 32-bit device (right) can complete the processing task faster, it’s out of its high-power mode quicker when the sleep interval and data-to-process remains constant. Also, note the difference in the baseline power consumption, with the 8-bit device having the lower of the two. The area under the curve represents total energy consumption. Therefore, the lower-power run-mode on the 8-bit device (left) isn’t necessarily an advantage.

Data-acquisition tasks from peripherals follow this principle, too. Turning on an ADC for short periods of time, only when needed, minimizes the time it’s actively consuming current. Interleaving the data acquisition and the processing tasks will result in more efficient power usage.

Low-power, low-frequency clock sources can be employed to manage sleep/wakeup cycles. Such a timer comes standard on most modern microcontrollers. If not available, then highly accurate and low-power 32.768-kHz watch crystals are an ideal substitute.

Conclusion
Hardware and software design for low power is application-specific. The key part of the process is to become intimately familiar with your product and its intended use case(s) before making any major design decisions.

Most of the design process depends on factors that change with each project. However, following some basic strategies, such as using power only when needed, managing parasitic peripherals, and being careful about clocking, can effectively minimize power consumption.