2.1 Overview of the msp430™ microcontroller from texas instruments  (Page 3/3)

• Device-specific errata sheet (e.g., MSP430G2553 device errata sheet ) . The errata sheet is a critical document that lists any device bugs that can affect a given use-case along with potential workarounds. Errata can vary by device as well as device revisions.

You can find these documents, as well as additional reference material such as application notes, example code and development tool documentation, by navigating to the device-specific product folder (e.g., MSP430G2553 product folder ) . Here, you can find the latest information as well as links to all pertinent documentation and software to aid your design efforts.

Arguably, the most valuable document is the device-specific data sheet. We have already looked at two core aspects (pinout and block diagram), but let’s dive a bit deeper into the information provided. The front page of the data sheet is designed to highlight all of the key aspects of the device organized into bulleted lists (Figure 4). It is comprehensive, showing typical power consumption, clock system capabilities, peripheral mix and package options.

This information is a great start, but is targeted as more of a marketing message than a reference. Going beyond the first page is critical to fully assess the given device’s capabilities and its limitations. Looking beyond the first page begins to yield the information needed to really design a system with the MSP430 MCU. This begins with the available options for the device and variants. For example, there are 40 device and orderable part number variants for the MSP430G2553 device. These variants provide different mixes of flash or RAM, peripherals available, number of I/Os supported, and package options such as DIP or surface-mount options.

While all information in a data sheet should be considered important, we recommend focusing on these areas when reviewing a data sheet for a specific MSP430 MCU:

• Supported interrupt sources, corresponding flags and priority (Figure 5).

• Calibration data such as internal clock defaults and ADC offset/gain settings (Figure 6).

• Timer functions and pinouts for each capture-compare I/O (Figure 7).

• Absolute maximum ratings and recommended operating conditions, including voltage and temperature, as well as CPU clock speeds vs. Vcc (Figure 8).

• Performance specifications for power consumption, analog accuracy, clock tolerances, etc. (Current consumption and ADC performance excerpts shown in Figure 9).

• Port schematics and pin function tables that detail exactly how to select a given multiplexed function on a given pin using the I/O control registers (Figure 10).

• Package information providing package tolerances, useful when creating device footprints in schematic/PCB CAD tools (Figure 11).

Now that we have reviewed the MSP430 device documentation and where to find information about what a device can do, let’s walk through the process of actually selecting the part that best suits a given design need.

Let’s start by answering the questions below:

• 1. “What problem am I trying to solve?” This is fundamental. Until you understand this, nothing else can happen. Knowing what problem you face at a system level allows you to identify how the MCU's features can help you solve that problem most efficiently.

• Do analog signals need to be measured, such as a voltage from a strain gauge or an output from a potentiometer? If so, perhaps an integrated ADC is of value. If a simple analog threshold is all you need, an integrated comparator will likely do the trick.
• What is the user interface? Switches likely translate into simple digital interrupt inputs, while displays may require a communication bus such as SPI in order to refresh the data displayed.
• Are time-sensitive signals needed off-chip? Perhaps you need a PWM signal to control a motor’s speed or LED brightness.
• What are the other devices or circuits that the MCU needs to interface with? Identifying potential analog inputs, logic-level digital I/O signals, or communication interfaces such as I2C or UART will all help you find the right MCU to fit the application need.

• 2. “How many 'things' need to be input into the device or driven from the device [as outputs])?” Determining this at a block level for the system, and then at a more detailed MCU pinout level, will clarify exactly how many I/O pins you will need.

• 3. “What are my power-supply requirements/limitations?” This is important, as the MCU supply may impact the overall system design. For example, if powered from a 9-V battery, the MSP430 MCU will need a regulator to bring its supply to within the 1.8- to 3.6-V range.

• 4. “How much memory will my application need?” This is not always obvious, as the software may not yet be written. But if you plan on using existing code, or modifying code already written, you can get an idea of what a given function in software might require in terms of program and data-memory needs. And when you need certain algorithms such as fast Fourier transform or filtering, you can often estimate RAM requirements before ever selecting the device by simulating the functions on a PC.

• 5. “Are any ‘special’ features needed?” For example, do you need a USB interface to a PC? Or a high-resolution ADC (>12 bits) to get a certain system performance? Consider looking for MCUs that offer such features integrated to minimize the system-level design effort and complexity required.

• 6. “Are there any physical design or assembly constraints (package size, pin spacing, PCB or assembly capability)?” Often, the box the final system must fit into is a factor. This can have big implications on package requirements, pin-count limits and PCB design complexity/cost. Also consider testing a final system – the more dense a design or package is with respect to PCB routing, the more challenging it is to assemble and debug. DIPs are easiest, with BGAs being quite challenging.

Numerous devices available in the MSP430 family portfolio can meet the given system requirements uncovered in these questions. We've listed a few in Table 1, with their own unique feature sets. A key driver in listing these specific parts is their ease of use. They are available in DIP packages and are supported by a flexible and scalable development tool that can accelerate prototyping of a given application.

Table 1. Three MSP430 devices with typical characteristics.

Each of the devices can be used with the MSP430 MCU LaunchPad to provide an easy, intuitive and out-of-the-box development experience (Figure 12).

Solving any design challenge begins by understanding the problem and any constraints that the system may have. Once you have established a clear picture of the problem you need to solve, finding the ideal way to solve that problem – using an MCU – can be straightforward if you understand the capabilities that MCUs offer. Being able to navigate the MSP430 family, its feature set, and the available devices and development tools are keys to success in meeting such a system design challenge.