| |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joseph Woolley wrote:
> Nick,
>
> Setting the timeslice to a low number (5ms is fairly low), negetively
> effects overall system performance. Time used by the operating system for
> task switching is taken away from applications. If a switch takes .5ms
> (for example) and you switch every 100ms, then you are incuring a cost of
> .5/(100+.5) (0.004975...); if you switch every 1ms, then the cost goes up
> to .5/(1+.5) (0.333...) In the first example (switching every 100ms) the
> processor spends less than 1/2 of 1 percent of its time performing task
> switching; in the second example (switching every 1ms) the processor
> spends
> 1/3rd of its time performing task switching. That is a big difference.
The OS should not impose conditions on the programmer. Just put in the docs
"numbers less than 5ms (the default) are not recommended" or something to
that effect.
>
> Now, the second, and likely more import item, is that even if the task
> switching is occuring every millisecond, your task may not get called that
> often. Even if your task is set to the highest priority, other tasks with
> that priority will get their turn. So if three tasks are running at top
> priority, each task has the ability to take 1/3rd of the processor time
> (not
> including the time taken by the operating system). Your task would then
> run every millisecond at best and every third millisecond at worst.
My code isn't a task. It's set as the timeslice handler. This is done from a
routine that is called from my main task; it sets it, waits for it to be
called a certain number of times, and resets to the default handler.
>
> Third, there are some minor points to consider:
> 1) If you plan on setting the motor controller every millisecond, you
> will
> not likely get the desired result. I have tried setting/changing the
> motor speed and direction at high frequencies (3 to 5 milliseconds between
> changes) and the motor seems to respond randomly. Usually producing very
> little power/movement.
I would expect that. Fortunately, my code doesn't need to touch the motors;
they just are set to run before and stopped afterward.
> 2) If you plan on checking a sensor reading that often, you will be
> disappointed. The sensor ports are read using an A/D converter which
> dictates the amount of time necessary per sensor. I believe some sensors
> (or sensor readings) may take longer than others. For example, a light
> sensor in bright light may take less time to read than the same sensor in
> darkness. This is a function of the A/D converter. The A/D conversion
> process likely takes more than 1, 2 or even 3ms per sensor (I want to find
> out how long this takes, actually)
The SENSORS file in the documentation directory says that even after ISR
overhead, sensor update frequency should be 8-10kHz.
> 3) A large amount of code being executed often can really slow things
> down.
> Again, I ran into this problem before. I wanted to get a machine to
> follow a line very closely, so I tried making it check the sensor very
> often and
> set the motor as quickly as it could. Basically the robot sat still and
> made a slight humming sound (it would have been great if that sound was my
> desired outcome... it was a nice soft hum LOL) I had to add sleep states
> to each of the tasks until each task was sleeping between 8 and 15
> milliseconds.
What I'm doing is reading a light sensor and storing the value in an array
once a millisecond. The amount of light is likely to vary greatly.
>
> Last, I am very interested to hear more about the problem/solution that
> you
> are implementing. I hope this information is helpful. • A scanner.
>
> // Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE93ufcoCEoi2uanUQRAhdFAKChx2HfHxuy48jh/kIK45lIqOQz6gCfWGGB
yWk15SWCWdl5gdTKq0NR1zc=
=oheP
-----END PGP SIGNATURE-----
|
|
Message is in Reply To:
 | | Re: Why...
|
| Nick, Setting the timeslice to a low number (5ms is fairly low), negetively effects overall system performance. Time used by the operating system for task switching is taken away from applications. If a switch takes .5ms (for example) and you switch (...) (22 years ago, 21-Nov-02, to lugnet.robotics.rcx.legos)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
