Multitasking tips - Revision history

Jwatson at 18:40, 13 August 2012

2012-08-13T18:40:37Z

Bfeher: /* Part 5 */

2012-05-16T20:27:33Z

Part 5

Bfeher at 20:24, 16 May 2012

2012-05-16T20:24:53Z

Bfeher: /* Part 1 */

2012-05-16T20:08:07Z

Part 1

Bfeher: /* Part 2 */

2012-05-16T20:07:25Z

Part 2

Bfeher: /* Part 3 */

2012-05-16T20:06:50Z

Part 3

Bfeher: /* Part 4 */

2012-05-16T20:06:25Z

Part 4

Bfeher: /* Part 4 */

2012-05-16T20:06:08Z

Part 4

Bfeher: /* Part 4 */

2012-05-16T19:38:08Z

Part 4

Bfeher at 19:26, 16 May 2012

2012-05-16T19:26:17Z

← Older revision		Revision as of 18:40, 13 August 2012
Line 6:		Line 6:
	<br />		<br />

		+	*'''Note: The following has been copied from various posts from the following thread: http://www.vexforum.com/showthread.php?t=53551'''
		+	<br />
	RobotC’s ability to run more than one task is IMHO it’s greatest strength, there has been lot’s written describing multi-tasking in it’s different forms but when dealing with RobotC I like to think of it as the ability to run more than one independent program at a time even though these programs are contained within one executable and downloaded together. For some background reading on multi-tasking, wikipedia is not a bad place to start. http://en.wikipedia.org/wiki/Computer_multitasking.		RobotC’s ability to run more than one task is IMHO it’s greatest strength, there has been lot’s written describing multi-tasking in it’s different forms but when dealing with RobotC I like to think of it as the ability to run more than one independent program at a time even though these programs are contained within one executable and downloaded together. For some background reading on multi-tasking, wikipedia is not a bad place to start. http://en.wikipedia.org/wiki/Computer_multitasking.

@@ Line 540: / Line 540: @@
 {{tip-from-author
 |name=jpearman
-|link=http://www.vexforum.com/showpost.php?p=226297&postcount=29
+|link=http://www.vexforum.com/showpost.php?p=227764&postcount=30
 }}
 <br />
-For the next experiment I’m going to delete the AbortTimeSlice command completely and see what the result is, here’s the modified code.<br />
+I’m going to conclude this short tutorial on multi tasking with a discussion of the remaining useful RobotC commands relating to tasks.
 {|
 |-
 |<syntaxhighlight lang="ROBOTC">
-// Flash the first LED
+StartTask( taskName );
-task flashLed_1()
+StartTask( taskName, priority );
-    while( true )
-−
-        // toggle output
-        SensorValue[ LED_1 ] = 1 - SensorValue[ LED_1 ];
-−
-−
 </syntaxhighlight>
 |}<br />

← Older revision		Revision as of 20:24, 16 May 2012
Line 535:		Line 535:

	You will notice that the main task (blue waveform) never runs, this is because the higher priority task does not give up control and therefore the task scheduler does not let the less important task run.		You will notice that the main task (blue waveform) never runs, this is because the higher priority task does not give up control and therefore the task scheduler does not let the less important task run.
		+	<br />
		+
		+	== Part 5 ==
		+	{{tip-from-author
		+	\|name=jpearman
		+	\|link=http://www.vexforum.com/showpost.php?p=226297&postcount=29
		+	}}
		+	<br />
		+
		+	For the next experiment I’m going to delete the AbortTimeSlice command completely and see what the result is, here’s the modified code.<br />
		+
		+	{\|
		+	\|-
		+	\|<syntaxhighlight lang="ROBOTC">
		+	// Flash the first LED
		+	task flashLed_1()
		+	{
		+	while( true )
		+	{
		+	// toggle output
		+	SensorValue[ LED_1 ] = 1 - SensorValue[ LED_1 ];
		+	}
		+	}
		+	</syntaxhighlight>
		+	\|}<br />

@@ Line 14: / Line 14: @@
 == Part 1 ==
 The difficulty in creating a simple multi-tasking example is that almost everything proposed can be done without using multi-tasking, however, just to illustrate the principles involved we will create a very simple piece of code to flash two leds on and off connected to different output ports.
@@ Line 153: / Line 160: @@
          |}
 <br />
 == Part 2 ==

@@ Line 162: / Line 162: @@
 == Part 2 ==
 The previous post contained a very simple example demonstrating RobotC multi-tasking that would flash two LEDs at different speeds, not very exciting but actually useful in some cases. The task, flashLed_1, will keep executing no matter what other code you are running. Perhaps the robot is under driver control, LED_1 keeps flashing, perhaps following a line in autonomous mode, LED_1 keeps flashing. Why it’s flashing I have no idea, perhaps bad battery, that’s up to the programmer.
@@ Line 379: / Line 385: @@
 |}<br />
 This is the main task and entry point for the program. The “MotorSlewRateTask” is started, the “ArcadeDrive” is started and then it enters a loop that does nothing. All control is handled by the other two tasks. Implementing main in this fashion allows the code to be moved into the competition template easily, to enter driver control simply start the two other tasks.
 == Part 3 ==

@@ Line 389: / Line 389: @@
 == Part 3 ==
 Consider a group of students sitting around a table having a discussion with their teacher. If a student wants to speak then they have to raise their hand and wait for the teacher to give them permission. If several students have their hands raised the teacher will choose each one in turn so everyone can be heard. Some students may want to speak often and keep raising their hands, others may be sleepy and not participate much at all. The teacher is also watching a clock, if a student speaks for too long then the teacher will interrupt them and give someone else a turn. At one point the school principle joins the debate, he also has to raise his hand to be able to speak but, as he is considered more important, the teacher always gives him priority.
@@ Line 462: / Line 468: @@
 You can observe that LED_1 is now flashing very fast as the only other task we have created is the main task which sleeps for 2mS before wanting to run. Both tasks still operate but the majority of the time is spent running the flashLed_1 task. If you are wondering what the large gap in the yellow trace is, well in the previous post I explained that RobotC already has other tasks running for debugging purposes, this gap occurred when the RobotC task, presumably a more important task, needed to run.
 == Part 4 ==

@@ Line 472: / Line 472: @@
 == Part 4 ==
 For the next experiment I’m going to delete the AbortTimeSlice command completely and see what the result is, here’s the modified code.<br />
@@ Line 533: / Line 538: @@
 You will notice that the main task (blue waveform) never runs, this is because the higher priority task does not give up control and therefore the task scheduler does not let the less important task run.

← Older revision		Revision as of 19:26, 16 May 2012
Line 468:		Line 468:
	\|link=http://www.vexforum.com/showpost.php?p=226282&postcount=28		\|link=http://www.vexforum.com/showpost.php?p=226282&postcount=28
	}}		}}
		+	<br />
		+
		+
		+	== Part 4 ==
		+	Consider a group of students sitting around a table having a discussion with their teacher. If a student wants to speak then they have to raise their hand and wait for the teacher to give them permission. If several students have their hands raised the teacher will choose each one in turn so everyone can be heard. Some students may want to speak often and keep raising their hands, others may be sleepy and not participate much at all. The teacher is also watching a clock, if a student speaks for too long then the teacher will interrupt them and give someone else a turn. At one point the school principle joins the debate, he also has to raise his hand to be able to speak but, as he is considered more important, the teacher always gives him priority.
		+
		+	This analogy describes quite well how the RobotC task scheduler works. The task scheduler (the teacher in my example) determines which task (student) can run. The principle represents a high priority task that has precedence over the others. When several tasks of the same priority want to run the scheduler chooses them in turn. If a task continues running too long then the scheduler stops it and gives time to others.
		+
		+	To show how this works in practice I’m going to use a modified version of the code presented a couple of posts back that flashes two LEDs. I’ve modified the code a little so that everything happens much faster and we can observe the signal going to the LEDs on an oscilloscope. An oscilloscope lets us look at the level of a signal (it’s voltage) over time and creates a graphical representation. More background on oscilloscopes is here http://en.wikipedia.org/wiki/Oscilloscope.
		+
		+	Here’s the test code we will use, very similar to before but the while loops only wait for 1mS and 2mS respectively.<br />
		+
		+	{\|
		+	\|-
		+	\|<syntaxhighlight lang="ROBOTC">
		+	#pragma config(Sensor, dgtl1, LED_1, sensorDigitalOut)
		+	#pragma config(Sensor, dgtl4, LED_2, sensorDigitalOut)
		+	//!!Code automatically generated by 'ROBOTC' configuration wizard !!//
		+
		+	// Flash the first LED
		+	task flashLed_1()
		+	{
		+	while( true )
		+	{
		+	// toggle output
		+	SensorValue[ LED_1 ] = 1 - SensorValue[ LED_1 ];
		+
		+	wait1Msec( 1 );
		+	}
		+	}
		+
		+	// Main task - flash the second LED
		+	task main()
		+	{
		+	// Start the other task
		+	StartTask( flashLed_1, 6 );
		+
		+	// Do our own thing
		+	while( true )
		+	{
		+	// toggle output
		+	SensorValue[ LED_2 ] = 1 - SensorValue[ LED_2 ];
		+
		+	wait1Msec( 2 );
		+	}
		+	}
		+	</syntaxhighlight>
		+	\|}<br />
		+
		+	If we observe the digital outputs on the scope we see the following, the value of LED_1 is shown by the yellow trace, LED_2 the blue. LED_1 is changing state every 1mS, LED_2 is changing state every 2mS. This corresponds exactly to the wait1Msec delays we have in the two tasks, each task does it’s thing and then sleeps until woken again by the task scheduler.<br />
		+
		+	[[File:tips-multitask-1.jpg]]
		+
		+
		+	For the next example we replace the wait1Msec(1) statement in the flashLed_1 task with a different command, AbortTimeSlice. This command hands control back to the task scheduler which then decides if any other tasks are waiting to execute (have their hands up), if none are waiting then control is given back to flashLed_1, lets see this on the scope.<br />
		+
		+	{\|
		+	\|-
		+	\|<syntaxhighlight lang="ROBOTC">
		+	// Flash the first LED
		+	task flashLed_1()
		+	{
		+	while( true )
		+	{
		+	// toggle output
		+	SensorValue[ LED_1 ] = 1 - SensorValue[ LED_1 ];
		+
		+	AbortTimeSlice();
		+	}
		+	}
		+	</syntaxhighlight>
		+	\|}<br />
		+
		+	[[File:tips-multitask-2.jpg]]
		+
		+
		+	You can observe that LED_1 is now flashing very fast as the only other task we have created is the main task which sleeps for 2mS before wanting to run. Both tasks still operate but the majority of the time is spent running the flashLed_1 task. If you are wondering what the large gap in the yellow trace is, well in the previous post I explained that RobotC already has other tasks running for debugging purposes, this gap occurred when the RobotC task, presumably a more important task, needed to run.
		+
		+
		+	{{tip-from-author
		+	\|name=jpearman
		+	\|link=http://www.vexforum.com/showpost.php?p=226297&postcount=29
		+	}}
		+	<br />