View Single Post
  #30  
Old 10-18-2011, 11:33 AM
jpearman's Avatar
jpearman jpearman is offline
Senior Member
VEX # 8888
 
Join Date: Apr 2011
Location: Los Angeles
Posts: 3,251
Re: RobotC programming tips

Iím going to conclude this short tutorial on multi tasking with a discussion of the remaining useful RobotC commands relating to tasks.

We have already used StartTask to start tasks with the default task priority or a user defined priority.

Code:
StartTask( taskName );

StartTask( taskName, priority );
We looked at how abortTimeslice ( and EndTimeSlice ) affect the way tasks run. Although I did not specifically discuss wait1Msec, itís importance in allowing the task scheduler to switch between tasks was demonstrated.

The following commands will be used less frequently.

Code:
StopAllTasks();
This does what itís name implies, stop all tasks from running including the main task. Not sure what the use of this really is other to terminate the program.

Code:
StopTask( taskName );
A bit more useful, stop the named task.

Code:
hogCPU();
releaseCPU();
The hogCPU command tells the task scheduler that the current task requires exclusive use of the cpu until either a releaseCPU call is made or the task sleeps. I donít see the need for this in ďnormalĒ competition software, it can be used to stop the task scheduler switching tasks in the middle of time critical processing but, as it does not stop the RobotC background tasks from running, even that use is marginal.

Code:
getTaskPriority( taskName );
setTaskPriority( taskName, newPriority );
Use these to get and set the task priority for a currently running task. As above, Iím not sure these have much use during ďnormalĒ competition programming.

Before concluding I wanted to discuss briefly how long tasks should sleep in their processing loop. The cortex is running a form of Real Time Operating System, (RTOS), however, real time operation of every task is an illusion as the cortex can in fact only do one thing at a time. The concept of real time is very flexible, when a button is pressed on the joystick to make an action happen, for example a motor running or stopping, how fast this has to happen and whether it is considered real time is purely from the perspective of the operator. For this type of action 0.1 seconds has been used as a rule of thumb in many situations and would imply that checking joystick buttons needs to happen no faster than perhaps twice this speed, say every 50mS. The point Iím trying to make is that most tasks do not need to run that often and can spend most of their time sleeping. Updating motors or checking sensors any more than 50 to 100 times a second is not necessary so an average task can have wait1Msec(20) at the end of the processing loop without any issues.

The next post will probably be about semaphores sometime later this week.
Reply With Quote