For discussion of multitasking, we need to define a task. In its simplest form a task is any one thing to done by a controller. Think of an army with an overall mission to accomplish and many individual soldiers to carry it out. The overall mission, ”Drive out that dictator,” is the job, but the tasks might be, ”Drive this supply truck to the front lines,” or, ”Sit in this trench until ordered to advance.” For a controller, a task might be to wait for and process input from a keyboard or to keep a motor running at a set speed. A task can be as simple as a single routine having a few lines of code, or it can be an entire set of nested routines. Task divisions can be arbitrary as long as they relate to the functional parts of the overall job. Most important, tasks represent a way of thinking that logically divides the job and leads to the effective use of the microcontroller.

Priority

Should a task ‘move to the head of the line’ when other tasks have been waiting longer to run? Having different priorities in a system implies that some activities are more important or more urgent than others. We are used to degrees importance in the realm of politics and big business, and we expect to yield to fire trucks and ambulances because they have greater urgency. The same thing can be applied to individual tasks. Issuing a pulse to a stepper motor may be more urgent than the computing an average. Stepper pulses must come at regular times, whereas a computation can be done whenever time is available. The first-level processing of incoming readings is more important than subsequent processing if the new readings will be overwritten by the next readings if they aren’t processed and moved. In a realtime system the priority may be a measure of importance or urgency, or it can reflect the duration of a task–a very short task could run with higher priority because it will be over and done quickly, rather than any inherent degree of importance.

Preemption

Should a task not just move to the head of the line, but stop and replace the task that is currently running? If so, it has preempted the running task. The concept isn’t difficult but the implementation can be challenging because the preempted task could be in the middle of something that shouldn’t be interrupted and, at a minimum, the various registers must be saved so the preempted task can resume where it left off when it gets to run again.

Most courses treat multitasking as an advanced topic. I hope your perspective will change as you come to see that it is the most fundamental part of efficient programming and deserves your attention as early as possible. Once you understand it, you can have your microcontroller look like it is doing many things all at the same time—it will never seem to be unavailable and will always be checking for something to do.

Beyond single-program thinking

If you have used only traditional techniques of programming, you will find, as your applications grow more time-critical, that a single program approach becomes awkward. When you have several external hardware devices that need to be served at the same time, your challenge is to make sure each device is satisfied.

Perhaps all your software has only had one thing happens at a time…in sequence (that is why computers were called sequential machines). If a speech chip had to say something, you programmed the processor to put out the appropriate code, pulse the write line, and then wait until the phrase was done before going on to check for some new input from the keypad. Nothing could be recognized while the processor was waiting for the ‘done’ from the speech chip. To move on in your programming skills you must develop a new way of thinking about program flow…you can’t let the flow get stuck if something isn’t ready yet.

Realtime

Although the term means different things to different people, I apply realtime to any system that respond to inputs and supply outputs fast enough to meet user or external hardware requirements. For example, a keyboard entry system is realtime if it gives you some feedback quickly enough for you to feel confident that the system “heard” you. If a “beep” is fed back to you within 100mSec, you feel confident that the system recognized the input “right away.” So, a keyscan routine that repeated every 100mSec would probably meet the requirement of fast enough. Likewise, your eyes and brain cannot assimilate new digital display information more quickly than perhaps 5 times a second….numeric values that are rapidly changing might better be updated only a few times a second. On the other hand, a stepper motor ought to be sent a new step pulse at a regular time with millisecond precision, so this is a much more critical time requirement. Most serial ports have a single-character buffer, so at 9600 baud every incoming character must be picked up within about 1mSec (10 bits @9600 bits/Sec=960 char/Sec »1mSec). Outgoing (asynchronous) characters can go whenever the processor is not busy, assuming there is no other time constraint on message transfer. The same considerations would apply to collecting data via an A-D converter. Depending on how rapidly the incoming voltage is changing, the reading might need immediate retrieval or might be held for quite some time. How rapidly should a flow valve be adjusted for a process? How quickly should a motor be supplied a new speed setting? All of these are questions relating to what is fast enough.