Scheduler:Traffic Light With Walk

Since the scheduler example for a traffic light of a week or two ago had nothing to do in the background, this next example uses the idle time to watch for a button push. The program is Figure 13.5, flowcharted in Figure 13.4. I add two buttons to be used by pedestrians to request a walk cycle. The scheduling of the light cycle will still happen in the real-time interrupt as before. I set up two flags (bits in walk) to keep track of anyone pushing the button (which comes in as a logic 0). By ORing the port with the variable, if the button was pushed previously, the logical OR will simply keep a 1 in that bit position. No matter how many people push the button, there will be just one walk cycle, and the bit can be cleared when the walk is actually provided. It is cleared by & ~0×02, which is a more understandable way of getting the 0xfd to clear that bit from a 1 to a 0. When a walk bit is detected, the switch expression substitutes a different pointer to give a walk instead of a normal light cycle. [This is very crude, and you would want a DON’T WALK light and perhaps a flashing period before the walk cycle ends. Also you would want to coordinate with turning cars, and so on. A true traffic light program is significantly more complicated than this.]

There are at least three options for keeping track of users pushing the walk buttons:

1. Polling in the main routine is the easiest way to recognize walk requests. This is the solution I have chosen to show here.
2. The buttons could be scanned in the scheduler interrupt itself—add another counter and once every 40th interrupt, perhaps, read the buttons. If there were much else for the processor to do, this would be the preferred solution because long background tasks (in main()) would not alter the button scanning.
3. The buttons could be tied to external interrupts. There are at least two of them, and they could be made edge-triggered so the software would interrupt whenever a button is pushed. This is a bit wasteful of hardware and has limited expansion capability—there aren’t many external interrupts. Besides, it is a waste of hardware when it can be done easily by the earlier methods.

Flowchart: Traffic Light With Walk

Traffic Light With Walk Buttons
#include<C8051F020.h>
#define uchar unsigned char
#define uint unsigned int
#define LEDS P1
#define WLKBTNS P3
uint countdown; uchar index,walk;
code struct{uint delay;uchar pattern;}cycle[]=
{{1000,0×12},{3000,0×41},{1000,0×21},
//(0)=—R,–Y-; (1)=-G–,—R; (2)=–Y-,—R;
{5000,0×14}, {3000,0xc1},{5000,0x1c}};
//(3)=—R,-G–; (4)=WG–,—R; (5)=—R,WG–;

void initialize(void){
WDTCN = 0×07; WDTCN = 0xDE;//Disable WDT WDTCN = 0xAD;
XBR2 = 0×40;//enable crossbar
P1MDOUT = 0xFF;//P3 push-pull out
OSCICN = 0×04;//enable int oscillator
countdown=1;//start at once
walk=0;//none pending
index=3;//lead to first state
TMOD=0×10;//tmr1 16-bit
TH1=~(1000/256);
TL1=-(1000%256);
TR1=1;//enable timer 1
IE=0×88;//enable timer1 int
}

void msecint (void) interrupt 3 using 1{
uchar i;
TH1=~(1000/256);TL1=-(1000%256);
if(–countdown==0){ //end of delay
++index;index%=4;i=index;
switch(index){//override for walk
case 1:if((walk&0×02)==0){
walk&=~0×02; i=4;
}
break;
case 3:if((walk&0×01)==0){
walk&=~0×01; i=5;
}
break;
}
LEDS=cycle[i].pattern;
countdown=cycle[i].delay;
}}

void main(void){
initialize();
while(1){
walk=walk | WLKBTNS;
}}

Communication by Shared Variable With the first solution I must get the value of walk to the scheduler from the main (background) program; in a formal sense you can say the two tasks communicate. In effect communication is by shared variable—walk is global and can be accessed by both the interrupt and the main program. Later chapters will go into other communication methods.

For the pattern going to the LEDs I arbitrarily chose to position the walk lights as the most significant bits of the nibbles.

Although the interrupt in this stoplight example has grown more complicated, the basic approach has not changed. The program flow never waits in the interrupt function. Rather, it moves through and returns to the main as quickly as possible.

A scheduler may seem too simple and too efficient to qualify as a multitasking operating system. You write all the code, there are no operating system commands to learn, and you can achieve full real-time performance. In one sense a scheduler just makes good use of a real-time clock. Yet the concept is so powerful it rates its own chapter [this post is from chapter13].

What is a scheduler?

Chapter 11 Hardware: Interrupts & Timers went into detail on the production of a regular interrupt—a real-time clock running tasks at specific times is a scheduler. It is an arrangement of software that calls task functions after a specific number of system ticks. Suppose you have a system tick every millisecond. You might have a keyscan task running every 40^th tick and a stepper motor pulse task being called every 10^th tick (100 steps/S). If the step rate changed, the scheduler might call the step function every 20 ticks (for a 50steps/S rate). All the activities key off counters initialized for a desired delay and then decremented every tick interval. When the counter for a specific task reaches zero, the count is reset, and the given task function is called.

Since scheduler tasks have to fit in between system ticks, you should write the code of any task to execute as quickly as possible and return. Never write while() or for(;;) loops in a task if exiting the loop depends on an outside event. Likewise, if there is a lot of processing to do, set a flag in the scheduler interrupt. Have the main function poll and detect that flag and then handle the processing in the background. Continue reading →