ECS Lab 1: Timer Basics

ECS Lab 1: Timer Basics

Level: Beginner

Study points: Real-time control structure, timer interrupts, C programming

The purpose of this first ECS (Embedded Control Systems) lab is to learn about basic real-time, multitasking control, with the use of a common peripheral available in most MCU’s and digital signal processors. Yes, we are talking about a timer module, which I quite believe many readers are already familiar with. Nevertheless, this hardware is essential for reliable digital control implementation so it’s worth discussing it to form a solid foundation for more advanced topics later on.

A common control algorithm can be thought of roughly as consisting of 3 basic operations: (1) read input from a sensor, (2) process or compute a control output, and (3) send the output to an actuator. These operations have to be repeated indefinitely so it makes sense to put them in an infinite loop. A novice might attempt to implement such control structure in a C main loop like shown in a pseudo-code below.

main( )
{
// initialization part omitted 
while (1)  // runs forever
{
	x = readAD( );		// read input from A/D module
	u = compute(x); 	 // compute control varialbles
	DAout (u);		// send output to D/A module
}

While this may work for some simplest application without specified stability/performance requirements, no serious control engineer would implement an algorithm this way. The main problem is a digital controller generally needs to execute at specified and constant period. This sampling time is a figure that cannot be violated for the controller to work reliably and conform to the desired stability and performance criteria crafted by its designer. So ,when you put an algorithm free-running in a main loop, there is so little chance that the execution time would match the desired controller sampling. Well, if one insists on this main-loop implementation, he/she might try to figure out the execution time (say, by counting all the instructions, or find a way to measure with an oscilloscope, assuming there is no other task with conditional branching that affects the loop time) and redesign the controller for such sampling time. Just give me a reason to go with such effort, when a timer is there for you to use.

When a timer is used, a single-loop controller structure changes to the following:


Figure 1: A single-loop control structure using timer interrupt

This configuration is named “cyclic executive” in [1]. We can see that the control algorithm is implemented as a timer ISR (Interrupt Service Routine), which is executed “independently” at each specified sampling period, leaving the main loop for less time-critical task. Strictly speaking, for a single MCU system, all threads in a program have to share the same processor. The interrupt handling mechanisms take care of scheduling depending on the priority of each task. We leave real-time scheduling issues for more advanced lab. Right now we concentrate on how to set up a timer for control purpose.

A simplified diagram for timer hardware is shown in Figure 2. The core consists of a counter, a period register (PR), and a comparator. The counter increases as it receives the clock input. Whenever the count matches the value in the PR, a timer interrupt is generated. So as a programmer you only have to put the right number into the PR for the timer to tick at a desired period. A proper initialization depends on a couple of factors such as the timer number (an MCU normally has more than one timer units), size (16 or 32 bit, some can be cascaded), clock frequency (may be prescaled to give wider range of interrupt period). The timer is then enabled to execute your control algorithm. The details are product-specific but the fundamentals are quite similar.


Figure 2: A simplified diagram of timer hardware

Comments

comments

Comments are closed.