Файл: Introduction to microcontrollers (G. Gridling, 2006).pdf

Figure 2.29: Maximum time between two events that can be measured without an overflow. Prescaler value P = 4, timer resolution r = 2.

Apart from these formulas, there is another interesting thing about input capture that you should be aware of, and this has to do with how and when the input capture register is read. As we have explained, the timestamp is stored in the input capture register when the event occurs, and most likely an ISR will be called to read this register. However, raising an interrupt takes several cycles, so it can happen that another input capture event occurs in this period. This second event will again cause the current timestamp to be stored in the input capture register, effectively overwriting the old value. The ISR, which was triggered by the first event, will then read the timestamp of the second event.

This is of course not really a problem yet, since all that happens is that you miss the first event and react to the second one. The real problem lies with microcontrollers that clear the IF bit automatically before executing the ISR. In this case, the second event may occur after the input capture IF has been cleared but before the ISR has read the input capture register. The second event will set the IF again and will overwrite the input capture register, so the ISR will read the timestamp of the second event. However, since the second event also sets the IF anew, as soon as the ISR is finished, it will be called again, this time to serve the second event, and will read the same timestamp as before. So as a result, you have reacted to both events, but have erroneously attributed the second event’s timestamp to both events, see Figure 2.30.

Figure 2.30: Both calls to the ISR read the timestamp of the second event.

There is not much you can do against this problem if it can occur, exept read the input capture register as soon as possible. You may also check whether successive timestamps are equal and in that case discard the first one. If you use a controller that allows (or even requires) you to set back the IF,

set it back after you have read the capture register. This will still cause you to lose events, though. Your best protection is to make sure that such events do not occur too close together. So the minimum interval between events should be larger than the interrupt latency plus the time until you read the capture register.

Like external interrupts in general, input capture suffers from noisy input signals. Hence, many controllers offer noise cancellation, which is generally implemented as outlined in Section 2.3.1 (several samples are taken and compared).

2.6.3Output Compare

The output compare feature is the counterpart to the input capture. For the latter, the timestamp gets stored whenever something interesting happens on the input line. With output compare, something happens on an output line when a certain time is reached. To implement this feature, the timer offers an output compare register, where you can enter the time at which the output compare event should happen. Whenever the counter value reaches this compare value, the output compare event is triggered. It can automatically set or clear an output line, or even toggle its state. It can also do nothing and simply raise an internal interrupt.

Output compare often comes with a reset option, which automatically resets the counter when the compare value is reached. This allows to set up a periodic interrupt (or output signal) with a minimum of effort.

2.6.4Pulse Width Modulation

The pulse width modulation (PWM) mode is a special case of the output compare. In it, the timer generates a periodic digital output signal with configurable high-time and period. Two registers form the main interface to the PWM, one for the period (also called duty cycle) and one for the high-time (or the low-time). Some timers only allow the user to configure the high-time, and either use the full timer range as the period or offer a restricted choice of possible periods. In addition to these registers, the timer module provides bits to enable PWM and possibly for mode control.

PWM signals are useful for a lot of things. Apart from their uses in simple d/a converters they can be used e.g. to implement ABS in cars, to dim LEDs or numeric displays, or for motor control (servos, stepper motors, speed control of dc motors).

The internal realization of PWM is actually quite simple and just uses the counter and two compares. There are two possible implementations, one using an up-counter (or down-counter) and one using an up-down counter. In the following explanations, we will assume that the user specifies the high time of the signal, which we will call the compare value, and that the period is given by the top value.

In the up-counter version, see Figure 2.31, the output is set to high when the counter reaches zero, and it is set to low when the counter reaches the compare value. As soon as the top value is reached, the counter is reset to zero. The advantage of this method is its resource-efficiency. However, if you can update the compare and top values anytime within the duty cycle, you can produce glitches in the PWM signal, which are invalid interim cycles. For example, if you set the top value below the current count value, the timer will count through its full range once before switching to the correct duty cycle.

Figure 2.31: PWM signal generated by an up-counter and the results of unbuffered updates.

Controllers which use this method may hence only take over new top and compare values when the counter reaches zero. If you set the compare value above the top value, the output will be constantly high.

In the up-down-counter version, see Figure 2.32, the counter first counts up from zero to the top value and then switches direction and counts down back to zero. The counter starts by setting the output to high and begins counting at zero. Whenever the compare value is reached on the upcount, the output is set to low. When the compare value is reached again on the downcount, the output is set back to high. As you can see, this results in a nice symmetrical signal with a period that can be twice as long as that of a pure up-counter. Again, asynchronous updates of the compare or top value can result in glitches, so the controller must buffer the values until zero is reached.

Figure 2.32: PWM signal generated by an up-down-counter.

In both versions, the attainable period is determined by the resolution of the timer. If the high time is set to zero or to (or above) the top value, this will generally result in a constant low or high signal.

2.6.5Exercises

Exercise 2.6.1 You only have two 8-bit timers on your 8-bit microcontroller but want to have a 16-bit timer for your application. Can you solve this problem in software? How does your solution work? What functions do you have to provide as an API (application program interface) to your timer? Do you have to think about asynchronous updates?

Exercise 2.6.2 Assume that your microcontroller has an operating frequency of 1 MHz and two timers, an 8- and a 16-bit timer. It is your task to select useful prescaler modes for the timers. Each

timer can have four such modes between 2 and 1024 (and the values must be powers of 2). Which prescaler modes would you assign and why?

Exercise 2.6.3 Assume that your microcontroller is clocked with 4 MHz and that it offers an 8-bit timer operating with this frequency. You want to use this timer to measure the duration between two external events. What bounds does this impose on the duration (minimum and maximum interval). How large is your measurement error? How does a prescale value of 256 affect your answers?

Exercise 2.6.4 If compare and top value updates are not buffered, how many different ways are there to produce a glitch when using an up-down-counter to generate a PWM signal? Give an example for each way you find. How would you solve the update problem? What if the controller can raise an interrupt whenever the PWM signal reaches zero?

Exercise 2.6.5 You want to measure the period of a periodic digital signal and decide to use the external event counter (pulse accumulator) for this purpose. Sketch how you can measure the period this way. How accurately can you measure the period? Compare this method to a solution with input capture.

2.7 Other Features

2.7.1Watchdog Timer

The watchdog timer, also sometimes called COP (computer operates properly), is used to monitor software execution. The basic idea behind this timer is that once it has been enabled, it starts counting down. When the count value reaches zero, a reset is triggered, thus reinitializing the controller and restarting the program. To avoid this controller reset, the software must reset the watchdog before its count reaches zero (“kick the dog”).

The target applications of the watchdog are immediately apparent: It is used to verify that certain positions in the program code are reached within a given period. Hence, whenever the program digresses from its normal execution flow and does not reset the watchdog in time, a reset will be triggered, which hopefully will solve the problem. This leads us to the large set of situations where the watchdog is not helpful: Whenever the program misbehaves, but manages to reset the watchdog in time, and in all situations where the reason the program did not reset the watchdog does not go away after the controller has been reset, the watchdog will have no useful effect.

Example: Watchdog Timer

A popular example for a watchdog operating properly and successfully recognizing a program error while at the same time being unable to do anything about it is NASA’s Mars Pathfinder mission of 1997a. The Pathfinder successfully landed on the surface and began its mission of gathering data. However, after a couple of days, it began to experience system resets which entailed data loss. As it turned out, the reason lay with the watchdog timer: The operating system, the embedded real-time system VxWorks, used the priority inheritance protocol to manage access to mutually exclusive sections (which may only be executed by at most one task at any time). However, this protocol suffers from the so-called priority inversion problem, which can cause a high-priority task to be delayed by a task of lower priority. This occured in the pathfinder mission, and since the delayed high-priority task was responsible for resetting the watchdog, the watchdog timed out and reset the system. This was actually not a bad idea, even though it cost NASA some data, since in a way it did resolve the situation. However, the reset did not remove the cause of the problem, which simply arose from the conditions on Mars, so the problem occured again and again.

aYou have probably already heard about this mission or will hear about it again, since besides the watchdog issue it is also very instructive in terms of software testing or rather lack thereof, and of course because of the scheduling problem it so effectively demonstrated.

Since the watchdog is used to monitor correct program execution, which means that it both checks whether the controller executes the correct instructions and whether the software at least manages to execute the watchdog reset instructions in time, it is set apart from the other controller modules to allow autonomous operation. As a consequence, the watchdog possesses its own internal oscillator and is hence not affected by sleep modes which shut down the system clock. The watchdog timer features its own enable bit and generally provides some mode bits which control its timeout period. To avoid turning off the watchdog accidentally (after all, if the controller behaves erratically, it may well accidentally clear the watchdog enable bit), a certain procedure has to be followed to turn off the watchdog or to modify its settings. The HCS12, for example, requires that the program first writes

0x55 and then 0xAA to the watchdog reset register. The ATmega16 requires the program to set two bits in a register to 1, and then to reset the watchdog enable bit within four cycles.

2.7.2Power Consumption and Sleep

Microcontrollers are often deployed in mobile devices which run on batteries. In consequence, low power consumption is an important asset for a micorocontroller. In order to reduce the energy consumption E, several techniques are possible.

Clocking Frequency Reduction

This technique allows the controller to operate as usual, but with a slower frequency. The energy consumption is

that is, it is proportional to the frequency. Since controllers have a static design, the frequency can be reduced arbitrarily (as opposed to processors, which have a dynamic design and hence rely on a minimum operating frequency to work properly).

In order to utilize this feature, the designer can of course statically clock the controller with the minimum frequency required to meet the timing requirements of the application. But with an appropriate circuit it is also possible to dynamically reduce the frequency whenever the controller does not have to meet tight timing constraints. So although the frequency may have to be high to do some urgent but infrequent computations, it can be turned down during the long intervals in which the controller only goes about its routine tasks.

Voltage Reduction

This method utilizes the fact that

that is, the energy consumption is proportional to the square of the operating voltage. Hence, a reduction of the operating voltage has a significant impact on the power consumption. Unfortunately, it is not possible to reduce the voltage arbitrarily. The controller is generally specified for a certain voltage range. If the voltage drops below this level, the controller may behave arbitrarily. The minimum voltage that still allows the controller to function correctly depends on the environmental conditions.

As with frequency reduction, voltage reduction may either be done statically or dynamically. It may be combined with a sleep mode, as in the 8051.

Shutdown of Unused Modules

This method utilizes the fact that the controller consists of several modules which may not all be in use at the same time. Since each active module draws power, it would obviously be a good idea to shut down unused modules. So if the controller only has to do internal computations, its bus or I/O components can be turned off for this duration. On the other hand, if the controller just waits for some external event, its CPU and other parts may be shut down until the event occurs. Note that shutting down the (digital) I/O module may entail that all pins are set to input, so you may not be able to drive an output pin and turn off the I/O at the same time.

This method is generally used for the sleep modes of a controller. Controllers tend to provide several different sleep modes, which differ in the components they shut down. Some modes even