Timers on the MSP430

 Timers on the MSP430

Summary: The Timer A and B systems on the MSP are a versatile means to measure time intervals.

The Timer A and B systems on the MSP are a versatile means to measure time intervals. The timers can measure the timing on incoming signals or control the timing on outgoing signals. This function is necessary to meet arbitrary timing requirements from outside components, and the ability is useful in phase locking scenarios etc.

The most basic operation of the timer systems is that the counter in the module counts upward for each clock cycle. The timer clocks can be sourced from both ACLK and SMCLK or from two special external sources INCLK or TBCLK. These last two use general I/O, but allow for a clocking speed not based on the others. The incoming source can be divided down by multiples of two before entering the counter. The user’s guide for the MSP has good diagrams on the architecture of the system in the respective sections for Timers A and B. Below the features and uses of Timer B are outlined.

Timer B Modes

Timer B is a flexible system. In addition to clock source selection and input clock dividing, the main counter itself can be set to count to 8, 10, 12 or 16 bits. The main counter can also vary its counting pattern among several options with the MCx bits of the Timer B Control Register TBCTL. These modes are:

1. Stop- the counter is not running
2. Up- the counter counts upward from zero to the value in Timer B Compare Latch 0 (TBCL0). When it gets to this value, it resets to zero. If the TBCL0 value is larger than the allowed maximum number of bits for Timer B, the counter behaves as if in Continuous mode.
3. Continuous- the counter counts from zero to the maximum value specified by the CNTLx bits of the TBCTL register. When the counter reaches this value, it resets to zero.
4. Up/down mode – the counter counts up to the value in TBCL0 then counts back down to zero (as opposed to resetting directly to zero). If the TBCL0 value is larger than the allowed maximum number of bits for Timer B, the counter behaves as if in Continuous mode.

Please note that the word count is used above- if the timer is set to a certain number it will not trigger anything. The timer must count from the number below to the target number to trigger effects.

Timer B Capture Compare Register 0

There are seven total capture compare registers in Timer B. While there is only one counter for all 7 modules, they can each interpret the count independently. The most important module is module 0 because it controls the timer with its TBCL0 register. Primarily it controls rollovers, but it also has its own dedicated interrupt. Setting this module up correctly is essential for desired operation of Timer B.

What is Capture/Compare?

A capture is a record of the timer count when a specific event occurs. The capture modules of the timers are tied to external pins of the MSP. When the control registers of timer B and the specific capture compare module have been properly configured, then the capture will record the count in the timer when the pin in question makes a specific transition (either from low to high or any transition). This capturing event can be used to trigger an interrupt so that the data can be processed before the next event. In combination with the rollover interrupt on Capture module 0, you can measure intervals longer than 1 cycle.

A compare operation is less intuitive than the capture, but it is basically the inverse of a capture. While capture mode is used to measure the time of an incoming pulse width modulation signal (a signal whose information is encoded by the time variation between signal edges), compare mode is used to generate a pulse width modulation (PWM) signal. When the timer reaches the value in a compare register, the module will give an interrupt and change the state of an output according to the other mode bits. By updating the compare register numbers, you change the timing of the signal level transitions.

This may sound somewhat complicated, but the basic concept of measuring (input) or controlling (output) the time interval between high to low and low to high transitions is all you need to know to start with. The MSP capture/compare modules have many different ways to perform each operation. This can be somewhat overwhelming, but it allows the microprocessor to handle inputs from a greater variety of other components. Capturing and comparing are done with the same modules, and each one can be configured individually. They can also be grouped using the TBCTL to trigger the capture compare registers to load simultaneously (useful for compare mode). The MSP430 User’s Guide fully details the behavior of the modules and the registers that control them.

Timer Interrupts

There are two interrupts related to timer B. One interrupt is dedicated to capture compare module 0; and, depending on configuration, it fires when the counter rolls back to zero. The second interrupt handles all 6 other capture compare registers, and fires to indicate that the module has captured or compared as explained above. Each module can be individually masked or enabled, and a special register stores which module caused the interrupt. As with all maskable interrupts, setting the general interrupt enable is necessary to receive them. The interrupts are important in being able to perform complex operations as new data arrives.

Improving Speed and Performance

 

Summary: In this lab we will focus on improving the performance of the MSP and attempt to optimize your code.

 

So far in this course, programming assignments have focused on functionality. In most applications of embedded programming, speed and power performance are equally important. Long battery life is won through judicious hardware and software design. Skillful programming will allow the same job to be done with cheaper parts to improve the bottom line. This lab will introduce the basic concepts behind power and speed performance improvement.

Speed Performance

It is well known from the consumer PC market that the speed of computers can be measured in hertz. It is less well known that the frequency of the computer's processor does not adequately indicate a computer's performance or even the performance of the processor itself. By using the ez430, the choice of processor and maximum speed has been made, but the question of speed is a different one in embedded programming. While the dominant paradigm in consumer personal computing is to increase the performance of the computer to allow the system to do more with each generation, embedded processors are chosen to be able to perform specific tasks. The cheapest processor that can meet the specifications for the design will be chosen. While the issue and business conditions make the situation much more complicated than just price, the pressure is still toward choosing a part with less performance, not more.

In order to improve the performance of a software application, it is necessary to understand the way performance is measured. Measuring performance between platforms and software packages is a problematic endeavor; improving the performance of a single program on a single platform is much simpler. Although a detailed explanation of the nuances of performance measurement in computing is beyond the scope of this lab, a simple way to gauge the amount of time a program will take to perform a task is to count the number of processor cycles that the code will take. On the MSP430, each CPU instruction, jump, and interrupt takes a fixed number of cycles as explained in the MSP430 User’s Guide. Taking into account branching, function calls, and interrupts the assembly code of a program can be used to calculate the time needed for a section of code.

Performance Tips

As mentioned above, embedded programming has different priorities from personal computing. Because the embedded programmer is usually trying to accomplish a specific task within a certain amount of time, the most important test of performance is whether the program is performing calculations on the inputs as fast as the inputs can enter the system. The goal is to make applications "real time." When the first draft of a program is unable to keep up with the required sampling, it is necessary to reduce execution time. Often, changing the hardware configuration is not easily doable; and software speed gains are usually more cost effective.

There are many approaches to improving speed performance. Incredible amounts of research go into new algorithms for common problems to improve the way that problem is solved. However, simply eliminating unnecessary instructions is a good start to improving performance. Test code left in a final version, any unnecessary instructions in a loop, and can all significantly increase the time in a section of code.

• In C, unnecessary code takes the form of too many method calls inside of a loop (because each method call adds a layer to the heap). While this is only a slight efficiency loss for code that is only executed once per sample, the loss can be very damaging if multiplied by a large loop. When trying to reduce execution time, it is best to start with the regions of the code where the processor spends the most time. Parts of the program that are only executed rarely have only a small effect on the speed compared to a loop that might run 100 times per sample. For example, if something can be done once, outside of the loop, do not do it many times inside of the loop.
• Remember to make judicious use of timers and other instruction saving interrupts. The timer interrupts allow the processor to periodically check on the status of the program without the use of slow while(1) or for(;;) loops (polling). However, for correct program behavior, it is important to do the minimum possible work in an interrupt. This is most important with interrupts that happen frequently because the control flow of the program can be thrown off when interrupts happen faster than the system can handle. If the same interrupt occurs a second time before the first occurrence of the interrupt has completed, program behavior is much more difficult to control (essentially we have a recursive interrupt call). It is much easier to simply ensure that the interrupt is short enough to avoid the danger all together.
• Also, avoid recalculating values. If a piece of information is reusable, save it rather than recalculating it to save time. Sometimes memory is so scarce that this may not be possible.
• Don’t output to the console while debugging unless you absolutely must. Program flow is hampered immensley and program behavior might not reflect the behavior without the debug statement. Use breakpoints instead because the execution of the program is paused and the processor does not have to use any extra resources.
• Don’t leave legacy code from previous revisions. If you believe you may no longer need a part of the program, comment it out and note what you did in the comments. Even seemingly innocuous statements here and there in your code can slow overall performance.