djsfantasi
- Joined Apr 11, 2010
- 9,163
You have a list of “tasks” (you can be more specific by defining what YOU think a task is).
You also have a scheduler. It’s purpose is to run each task when appropriate. In your case, the scheduler is or is driven by the ISR. “Appropriate” in the example is defined by your table of start/stop times. With three LEDs, the task list consists of six entries (2 tasks x 3 LEDs)
When a task is scheduled to run, you execute its code. This is determined by a “scheduler “. In click_here’s example, the scheduler is the select/case construct testing if the tick count indicates whether or not to turn on/off a specific LED.
Otherwise, you wait for a scheduled event to occur. This is the while loop in the example.
Then, if it’s scheduled to run, you execute the tasks code. In the example, it’s just turning on/off an LED.
Thus, the example given on early IS a “cooperative multitasking program . There are different schemes for multi-tasking. There is cooperative multi-tasking in which a task runs until it returns control to the scheduler. There is multi-tasking by time slicing, in which a given tasks is only given so much time to complete before the scheduler is given back control. TRUE multitasking in implemented at the OS level and includes the control to spawn, determine state. and terminate individual programs.
In the example, the tasks are so simple, they are embedded in the scheduler (again, the select/case structure).
Note that in my description, if you replace “LED” with “device”, it has nothing to do with LEDs. A device could be an LED, servo, motor, sound player, sensor, etc…
I’ve written a cooperative multi-tasking program to implement run-time control of 12+ devices (RC servos) and other peripherals. It CAN support up to 255 tasks but in practice more than a dozen or two are only used. So I’m familiar with what you’re trying to do.
You also have a scheduler. It’s purpose is to run each task when appropriate. In your case, the scheduler is or is driven by the ISR. “Appropriate” in the example is defined by your table of start/stop times. With three LEDs, the task list consists of six entries (2 tasks x 3 LEDs)
When a task is scheduled to run, you execute its code. This is determined by a “scheduler “. In click_here’s example, the scheduler is the select/case construct testing if the tick count indicates whether or not to turn on/off a specific LED.
Otherwise, you wait for a scheduled event to occur. This is the while loop in the example.
Then, if it’s scheduled to run, you execute the tasks code. In the example, it’s just turning on/off an LED.
Thus, the example given on early IS a “cooperative multitasking program . There are different schemes for multi-tasking. There is cooperative multi-tasking in which a task runs until it returns control to the scheduler. There is multi-tasking by time slicing, in which a given tasks is only given so much time to complete before the scheduler is given back control. TRUE multitasking in implemented at the OS level and includes the control to spawn, determine state. and terminate individual programs.
In the example, the tasks are so simple, they are embedded in the scheduler (again, the select/case structure).
Note that in my description, if you replace “LED” with “device”, it has nothing to do with LEDs. A device could be an LED, servo, motor, sound player, sensor, etc…
I’ve written a cooperative multi-tasking program to implement run-time control of 12+ devices (RC servos) and other peripherals. It CAN support up to 255 tasks but in practice more than a dozen or two are only used. So I’m familiar with what you’re trying to do.
Last edited: