Subject:
|
Ticks for start_process
|
Newsgroups:
|
lugnet.robotics.handyboard
|
Date:
|
Mon, 30 Jun 1997 15:57:48 GMT
|
Original-From:
|
Randy Sargent <rsargent@newtonlabs.com+IHateSpam+>
|
Viewed:
|
1452 times
|
| |
|
|
Hi Sriram,
The "ticks" argument to start_process won't do what you want.
The "ticks" argument to start_process is used for fine-tuning the relative
amount of time different processes get. The number defines a single time
"slice" -- that is, the amount of time a process gets before it is
unscheduled and a new process is scheduled. After all the other processes
have gotten their turn, this process will again get "ticks" time to run,
and so on. "ticks" is not a total time limit on the running of a process.
Typical values for the number of ticks are between 2 and 10 (meaning 2 to
10 milliseconds.) "1" is fairly inefficient, and the largest value
possible is 254. "250" would literally mean give the process 1/4 of a
second at a time, which would make the performance of the other processes
suffer.
What you probably really want to do is something like this (beware;
untested code):
...
start_process(backup());
...
void backup()
{
/* insert your own backup code here! */
bk(0);
bk(2);
sleep(3.0);
/* insert your own forward code here! */
fd(0);
fd(2);
/* now the function exits, so the process ends */
}
Depending on what you actually want "backup" to do, you might want to
modify the above to either:
1) Set some global value to inhibit other processes from setting the motor
(this would be a typical "subsumption" approach).
2) If you really don't want any other process to touch the motors, and
there's no other reason to run the other processes while backing up, then
simply call "backup()" rather than start it as a separate process.
I hope this helps.
-- Randy
> Hi Everyone,
>
> While using the multitasking facilities of IC, is there a
> limit on the time allowed for each process (# of ticks).
>
> for instance can i define
> start_process(backup(),3000); (3 seconds)
>
> assumin that all activities within this process 'll not exceed
> 3000 msec. By doing this i can avoid using hog_processor() command
> which according to the HB manual could wedge the program..
>
> is this true? any help 'll be appreciated.
>
> Thanks
> SRIRAM
----------------------------------------------------------------
Randy Sargent Newton Research Labs
Senior Design Engineer Robotic Systems and Software
rsargent@newtonlabs.com http://www.newtonlabs.com/
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
